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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
