| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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 06:00:47 |
| Message-ID: | 3D4B718F.1020409@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> No, it was a 2% hit on rather slow functions with only one call made
> per query issued by the client. This is not much of a stress test.
>
> A more impressive comparison would be
>
> select 2+2+2+2+2+2+ ... (iterate 10000 times or so)
>
> and see how much that slows down.
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
#define INDEX_MAX_KEYS 16, 32, 64, & 128
#define FUNC_MAX_ARGS INDEX_MAX_KEYS
make all
make install
initdb
The results were as follows:
INDEX_MAX_KEYS 16 32 64 128
-----+-------+------+--------
Time in seconds 48 49 51 55
Joe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2002-08-03 10:07:50 | Re: []performance issues |
| Previous Message | Tom Lane | 2002-08-03 04:14:48 | Re: char/varchar truncation |