| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| 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:06:04 |
| Message-ID: | 20160114170604.GJ10941@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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.
Do we want to provide a backward compatible API for all this? I'm fine
either way.
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-01-14 17:07:23 | Re: Performance degradation in commit ac1d794 |
| Previous Message | Robert Haas | 2016-01-14 16:46:07 | Re: tiny doc patch |