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 по дате отправления: