From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Going, going, GUCs! |
Date: | 2009-10-21 05:44:52 |
Message-ID: | alpine.GSO.2.01.0910210132310.1418@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 20 Oct 2009, David Fetter wrote:
> commit_delay (no need for this knob)
> commit_siblings (no need for this knob)
Both these knobs do something that's valuable sometimes: help group
commits into bigger chunks when there are lots of active clients. I've
watched it help a bit on heavy writes at a client site before, and some of
the Sun benchmarks that have been published got a little boost out of it
too in a similar situation.
The use case for both is pretty narrow, and isn't actually the same one
the feature was intended to fix (originally this was supposed to be useful
more for the person who can't commit very fast at all; it isn't). But
there is some value, and the code involved is pretty small, not much
beyond the GUC overhead.
I'd like to get both pruned out in favor of a better chunking write
implementation that's aimed squarely at the problem these two help on
accidentally. Until that point, it's hard to justify wiping them out when
they do have some value and little code overhead to keep around.
As a comment on one of the larger themes brought up in this thread, I
don't think picking off a few parameters is of any value to making the
postgresql.conf file easier to work with. That needs a much larger
pruning before moving in that direction is actually going to help anyone.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2009-10-21 07:40:13 | Re: Client application name |
Previous Message | Itagaki Takahiro | 2009-10-21 04:24:10 | Re: Going, going, GUCs! |