On Thu, 6 Mar 2008, Bruce Momjian wrote:
Should we remove these now that we have async commit?
#commit_delay = 0 # range 0-100000, in
microseconds
#commit_siblings = 5 # range 1-1000
They seem unfixable.
commit_delay offers a small but not insignificant improvement for some
people using the feature under bursty, high client loads. The useful
tuning seems to be siblings>[10-20] and a small setting for the delay; I
usually just set it to 1 which gives the minimum the OS is capable of
resolving.
That wasn't the feature's original intention I think, but that's what it's
useful for regardless. As async commit is only applicable in cases where
it's OK to expand the window for transaction loss, removing commit_delay
will cause a small performance regression for users who have tuned it
usefully right now.
I actually have a paper design for something that builds a little model
for how likely it is another commit will be coming soon that essentially
turns this into something that can be tuned automatically, better than any
person can do it. No idea if I'll actually build that thing, but I hope
it's obvious that there's some possibility to improve this area for
applications that can't use async commit. If you're going to dump the
feature, I'd suggest at least waiting until later in the 8.4 cycle to see
if something better comes along first.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
