Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Date: 2012-05-31 15:34:22
Message-ID: CAEYLb_W4PBd=jEM-5rGCGbYoEi4nE9n1LU8cqBq2Yz=Aedn2kQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31 May 2012 16:26, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> On 31 May 2012 16:23, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>>> In what way is it possibly destabilising?
>>
>> I'm prepared to believe that it only affects performance, but it could
>> be destabilizing to that.  It needs proper review and testing, and the
>> next CF is the right environment for that to happen.
>
> It couldn't possibly be as destabilising to performance as
> commit_delay was in 9.1.

Furthermore, it couldn't possibly affect performance in any way unless
commit_delay is set. I've just moved the delay site so that its only
executed by the group commit leader. The leader would execute the code
anyway, but now the followers don't.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2012-05-31 15:34:50 Re: hash index concurrency
Previous Message Claudio Freire 2012-05-31 15:33:52 Re: [HACKERS] pg_dump and thousands of schemas