| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joe Conway <mail(at)joeconway(dot)com> |
| Cc: | 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 16:41:35 |
| Message-ID: | 3493.1028392895@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Looks like we could go for 32 without much problem, though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2002-08-03 16:47:10 | fate of CLUSTER command ? |
| Previous Message | Tom Lane | 2002-08-03 16:30:09 | Re: getpid() function |