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