Re: FUNC_MAX_ARGS benchmarks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FUNC_MAX_ARGS benchmarks
Date
Msg-id 3493.1028392895@sss.pgh.pa.us
Whole thread Raw
In response to Re: FUNC_MAX_ARGS benchmarks  (Joe Conway <mail@joeconway.com>)
Responses Re: FUNC_MAX_ARGS benchmarks  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
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.

Looks like we could go for 32 without much problem, though.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: getpid() function
Next
From: Oleg Bartunov
Date:
Subject: fate of CLUSTER command ?