Re: Going, going, GUCs!

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Going, going, GUCs!
Дата
Msg-id alpine.GSO.2.01.0910210132310.1418@westnet.com
обсуждение исходный текст
Ответ на Going, going, GUCs!  (David Fetter <david@fetter.org>)
Список 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@gregsmith.com http://www.gregsmith.com Baltimore, MD


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Itagaki Takahiro
Дата:
Сообщение: Re: Going, going, GUCs!
Следующее
От: Dave Page
Дата:
Сообщение: Re: Client application name