| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Васильев Дмитрий <d(dot)vasilyev(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Performance degradation in commit ac1d794 |
| Date: | 2016-01-14 17:07:23 |
| Message-ID: | CA+TgmoanS+7wpYZeX1C5Vp1XL56XK7f3mx1T+94QDN0_a+y3Jw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 14, 2016 at 12:06 PM, Andres Freund <andres(at)anarazel(dot)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(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-01-14 17:10:15 | Re: Performance degradation in commit ac1d794 |
| Previous Message | Andres Freund | 2016-01-14 17:06:04 | Re: Performance degradation in commit ac1d794 |