"Stefan Kaltenbrunner" <stefan@kaltenbrunner.cc> 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
