"Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes: > Jignesh K. Shah wrote: >> Can you list others that seemed out of place?
The one which surprised me the most was the commit_delay setting. What results led you to set that? The common wisdom on this setting is that it doesn't accomplish its goals and does more harm than good for most cases and should be replaced with something more effective. In any case I wouldn't think the use case for a feature like this would actually apply in the case of a benchmark. The use case where something like this is needed is where there are not enough concurrent requests to keep the server busy during the fsync of the wal. If for example each query does 5ms of actual work and fsyncs take 15ms then you could be committing up to 3 transactions in one fsync and need another 3 busy connections to keep the server busy during that fsync so you would need at least 6 concurrently busy connections. If you have a more cpu-bound system then that number might be higher but 100+ connections ought to be enough and in any case I would expect a benchmark to be mostly disk-bound. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq