Re: Group commit and commit delay/siblings

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Group commit and commit delay/siblings
Дата
Msg-id 1291834852.2872.1168.camel@ebony
обсуждение исходный текст
Ответ на Re: Group commit and commit delay/siblings  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-performance
On Mon, 2010-12-06 at 23:52 -0500, Greg Smith wrote:
> Jignesh Shah wrote:
> > On Tue, Dec 7, 2010 at 1:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> >> I could have sworn we'd refactored that to something like
> >>        bool ThereAreAtLeastNActiveBackends(int n)
> >> which could drop out of the loop as soon as it'd established what we
> >> really need to know...I'd suggest that we just improve the
> >> coding so that we don't scan ProcArray at all when commit_siblings is 0.
> >>
> >> (I do agree with improving the docs to warn people away from assuming
> >> this is a knob to frob mindlessly.)
> >>
> > In that case I propose that we support commit_siblings=0 which is not
> > currently supported. Minimal value for commit_siblings  is currently
> > 1. If we support commit_siblings=0 then it should short-circuit that
> > function call which is often what I do in my tests with commit_delay.
> >
>
> Everybody should be happy now:  attached patch refactors the code to
> exit as soon as the siblings count is exceeded, short-circuits with no
> scanning of ProcArray if the minimum is 0, and allows setting the
> siblings to 0 to enable that shortcut:

Minor patch, no downsides. Docs checked. Committed.

--
 Simon Riggs           http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services



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

Предыдущее
От: Bryce Nesbitt
Дата:
Сообщение: hashed subplan 5000x slower than two sequential operations
Следующее
От: Shrirang Chitnis
Дата:
Сообщение: Re: hashed subplan 5000x slower than two sequential operations