On Fri, 26 Jun 2009, Scott Mead wrote:
Having those settings enabled basically does the following: " Do not complete the I/O for a commit until you have either commit_siblings commits also ready, or you have waited .55 seconds." Basically, if you make 1 commit, you will sit there waiting until either 99 other commits take place, or ~ 1/2 second goes by.
You're right that it should be removed, but this explanation is wrong. The behavior as configured is actually "if there are >=100 other transactions in progress, wait 0.1 second before committing after the first one gets committed", in hopes that one of the other 100 might also join along in the disk write.
Since in this case max_connections it set to 100, it's actually impossible for the commit_delay/commit_siblings behavior to trigger give this configuration. That's one reason it should be removed. The other is that i general, if you don't exactly what you're doing, you shouldn't be touching either parameters; they don't do what people expect them to and it's extremely unlikely you'll encounter any of the rare use cases where they might help.
I don't think any of the sync or write parameters have anything to do with this problem though, it seems like a problem with the referential bits taking too long to execute.
-- * Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
