Re: Performance degradation in commit ac1d794 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Performance degradation in commit ac1d794
Date
Msg-id CA+TgmoanS+7wpYZeX1C5Vp1XL56XK7f3mx1T+94QDN0_a+y3Jw@mail.gmail.com
Whole thread Raw
In response to Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
Responses Re: Performance degradation in commit ac1d794  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Jan 14, 2016 at 12:06 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-01-14 11:31:03 -0500, Robert Haas wrote:
>> On Thu, Jan 14, 2016 at 10:56 AM, Andres Freund <andres@anarazel.de> wrote:
>> I think your idea of a data structure the encapsulates a set of events
>> for which to wait is probably a good one.  WaitLatch doesn't seem like
>> a great name.  Maybe WaitEventSet, and then we can have
>> WaitLatch(&latch) and WaitEvents(&eventset).
>
> Hm, I'd like to have latch in the name. It seems far from improbably to
> have another wait data structure. LatchEventSet maybe? The wait would be
> implied by WaitLatch.

I can live with that.

> So effectively we'd create a LatchEventSet feLatchSet; somewhere global
> (and update it from a backend local to the proc latch in
> SwitchToSharedLatch/SwitchBackToLocalLatch()). Then change all WaitLatch
> calls to refer to those.

Sure.

> Do we want to provide a backward compatible API for all this? I'm fine
> either way.

How would that work?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Performance degradation in commit ac1d794
Next
From: Tom Lane
Date:
Subject: Re: Performance degradation in commit ac1d794