| From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Open 7.3 items |
| Date: | 2002-08-01 08:22:25 |
| Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961E37@m0114.s-mxs.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > > NAMEDATALEN - disk/performance penalty for increase, 64, 128?
> > > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
> >
> > At the moment I don't see a lot of solid evidence that increasing
> > NAMEDATALEN has any performance penalty. Someone reported about
> > a 10% slowdown on pgbench with NAMEDATALEN=128 ... but Neil Conway
> > tried to reproduce the result, and got about a 10% *speedup*.
> > Personally I think 10% is well within the noise spectrum for
> > pgbench, and so it's difficult to claim that we have established
> > any performance difference at all. I have not tried to measure
> > FUNC_MAX_ARGS differences.
>
> Yes, we need someone to benchmark both the NAMEDATALEN and FUNC_MAX_ARGS
> to prove we are not causing performance problems.
I think a valid NAMEDATALEN benchmark would need to use a lot of tables,
like 1000-6000 with 10-100 columns each. The last bench was iirc done with
pgbench that only uses a few tables. (The name type is fixed length)
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jean-Michel POURE | 2002-08-01 08:43:18 | Re: Open 7.3 items |
| Previous Message | Alvaro Herrera | 2002-08-01 07:55:46 | Re: Open 7.3 items |