Re: FUNC_MAX_ARGS benchmarks

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FUNC_MAX_ARGS benchmarks
Date: 2002-08-03 18:56:56
Message-ID: 1028401016.29120.5.camel@taru.tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2002-08-03 at 18:41, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2002-08-03 19:15:28 Re: fate of CLUSTER command ?
Previous Message Joe Conway 2002-08-03 18:56:06 cvs changes and broken links