Tom Lane wrote:
> http://archives.postgresql.org/pgsql-performance/2010-12/msg00073.php
>
> Possibly it should have been posted to -hackers instead, but surely you
> read -performance?
>
Trying to figure out what exactly commit_delay and commit_siblings did
under the hood was actually the motivation behind my first foray into
reading the PostgreSQL source code. Ever since, I've been annoyed that
the behavior didn't really help the way it's intended, but was not sure
what would be better. The additional input from Jignesh this week on
the performance list suddenly made it crystal clear what would preserve
the good behavior he had seen, even improving things for his case, while
also helping the majority who won't benefit from the commit_delay
behavior at all a little. I immediately wrote the patch and breathed a
sign of relief that it was finally going to get better.
I then posted the patch and added it to the January CF. Unbeknownst to
me until today, Simon had the same multi-year "this itches and I can't
make it stop" feel toward these parameters, and that's how it jumped the
standard process.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
