From: | Jignesh Shah <jkshah(at)gmail(dot)com> |
---|---|
To: | Rob Wultsch <wultsch(at)gmail(dot)com> |
Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Group commit and commit delay/siblings |
Date: | 2010-12-06 03:03:28 |
Message-ID: | AANLkTimFuhq5_q5TP75-9HS4uw5bDHPi18f9OqrmHUT7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Dec 6, 2010 at 10:47 AM, Rob Wultsch <wultsch(at)gmail(dot)com> wrote:
> On Sun, Dec 5, 2010 at 7:30 PM, Jignesh Shah <jkshah(at)gmail(dot)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(at)gmail(dot)com
>
I would say commit_siblings should go away but maybe keep commit_delay
for a while. The advantage of keeping commit_delay is to do a rhythmic
write patterns which can be used to control writes on WAL. It is
debatable but I had used it couple of times to control WAL writes.
To me commit_siblings is expensive during heavy users/load and should
be killed.
My 2 cents.
Regards,
Jignesh
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-12-06 04:35:32 | Re: Group commit and commit delay/siblings |
Previous Message | Rob Wultsch | 2010-12-06 02:47:33 | Re: Group commit and commit delay/siblings |