Re: Group commit and commit delay/siblings
От | Rob Wultsch |
---|---|
Тема | Re: Group commit and commit delay/siblings |
Дата | |
Msg-id | AANLkTikOHMnjTZh94AT2nkeDGCyDyAzOhuDpQFzm9OSi@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Group commit and commit delay/siblings (Jignesh Shah <jkshah@gmail.com>) |
Ответы |
Re: Group commit and commit delay/siblings
|
Список | pgsql-performance |
On Sun, Dec 5, 2010 at 7:30 PM, Jignesh Shah <jkshah@gmail.com> wrote: > The commit_siblings = 5 basically checks that it sleeps only when that > many backends are active. This I think is a very expensive check and I > would rather make commit_siblings=0 (which the current code does not > support.. it only supports minimum of 1) The check is expensive > irrespective of the settings .. But anyway here is the real kicker. > In all the tests I did with recent verions 8.4 and version 9.0 , it > seems that the default behavior handles the load well enough and one > does not have to use commit_delay at all. Since when the load is very > high all of them are basically in sync phase and the desired thing > happens anyway. > > Infact using commit_delay will actually add the cost of doing > commit_siblings check and can hurt the performance by increasing CPU > consumption.. Doing commit_siblings check for every transaction is a > killer since it does not return after meeting the minimum backends and > goes through every backend to calculate the total number before > comparing with the minimum. This is probably why most people see a > drop in performance when using commit_delay compared to the default. > > Anyway I would recommended right now to stick with the default and > not really use it. It does the sync absorbtion well if you have two > many users (though not perfect). Sounds like this setting should go away unless there is a very good reason to keep it. -- Rob Wultsch wultsch@gmail.com
В списке pgsql-performance по дате отправления: