From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL publishes first real benchmark |
Date: | 2007-07-12 09:08:38 |
Message-ID: | 4695EF96.3060009@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jignesh K. Shah wrote:
> Can you list others that seemed out of place?
well to me the ones that look most questionable are:
work_mem=100MB - so this benchmark is really low concurrency(which does
not fit with max_connections=1000) and with trivial queries ?
enable_seqscan = off - why ?
effective_cache_size = 40GB - on a box with 16GB this seems wrong
especially since there are some indications out there that suggest that
while overestimating effective_cache_size was not a problem in versions
<8.2 it might not be so in 8.2 and up
wal_buffers = 2300 - there have been some numbers reported that going
over the default of 8 helps but it is generally considered that going
beyond 500 or maybe 1000 does not help at all ...
and one more is that you claim you used "-fast -O4 -xtarget=ultraT1"
which is something we explicitly advise against in our own
FAQ(http://www.postgresql.org/docs/faqs.FAQ_Solaris.html):
"Do not use any flags that modify behavior of floating point operations
and errno processing (e.g.,-fast). These flags could raise some
nonstandard PostgreSQL behavior for example in the date/time computing."
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-07-12 10:45:16 | Re: PostgreSQL publishes first real benchmark |
Previous Message | Marc Cousin | 2007-07-12 08:55:07 | Re: Weird row estimate |