Re: Performance degradation in commit ac1d794
От | Robert Haas |
---|---|
Тема | Re: Performance degradation in commit ac1d794 |
Дата | |
Msg-id | CA+TgmoanS+7wpYZeX1C5Vp1XL56XK7f3mx1T+94QDN0_a+y3Jw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Performance degradation in commit ac1d794 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Performance degradation in commit ac1d794
Re: Performance degradation in commit ac1d794 Re: Performance degradation in commit ac1d794 |
Список | 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 по дате отправления: