Re: FUNC_MAX_ARGS benchmarks
Hannu Krosing <hannu@tm.ee>
From: Hannu Krosing <hannu@tm.ee>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Joe Conway <mail@joeconway.com>, Bruce Momjian <pgman@candle.pha.pa.us>, Thomas Lockhart <lockhart@fourpalms.org>, Neil Conway <nconway@klamath.dyndns.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2002-08-03T18:56:56Z
Lists: pgsql-hackers
On Sat, 2002-08-03 at 18:41, Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: > > I ran a crude test as follows (using a PHP script on the same machine. > > Nothing else going on at the same time): > > > do 100 times > > select 2+2+2+2+2+2+ ... iterated 9901 times > > > The results were as follows: > > INDEX_MAX_KEYS 16 32 64 128 > > -----+-------+------+-------- > > Time in seconds 48 49 51 55 > > Okay, that seems like a good basic test. > > Did you happen to make any notes about the disk space occupied by the > database? One thing I was worried about was the bloat that'd occur > in pg_proc, pg_index, and pg_proc_proname_args_nsp_index. Aside from > costing disk space, this would indirectly slow things down due to more > I/O to read these tables --- an effect that probably your test couldn't > measure, since it wasn't touching very many entries in any of those > tables. How hard would it be to change pg_proc.proargtypes from oidvector to _oid and hope that toasting will take care of the rest ? This could also get the requested 2% speedup, not to mention the potential for up to 64K arguments ;) --------------- Hannu