Re: perform_spin_delay() vs wait events
От | Alexander Korotkov |
---|---|
Тема | Re: perform_spin_delay() vs wait events |
Дата | |
Msg-id | CAPpHfdtK_bGDR=hAXDAZQCgzScdHjgr=QwTTgsdDo4KFi6DBjg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: perform_spin_delay() vs wait events (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: perform_spin_delay() vs wait events
|
Список | pgsql-hackers |
On Tue, Nov 22, 2022 at 12:01 AM Andres Freund <andres@anarazel.de> wrote: > On November 21, 2022 12:58:16 PM PST, Alexander Korotkov <aekorotkov@gmail.com> wrote: > >On Mon, Nov 21, 2022 at 2:10 AM Andres Freund <andres@anarazel.de> wrote: > >> On 2022-11-20 17:26:11 -0500, Robert Haas wrote: > >> > On Sun, Nov 20, 2022 at 3:43 PM Andres Freund <andres@anarazel.de> wrote: > >> > > I couldn't quite decide what wait_event_type to best group this under? In the > >> > > attached patch I put it under timeouts, which doesn't seem awful. > >> > > >> > I think it would be best to make it its own category, like we do with > >> > buffer pins. > >> > >> I was wondering about that too - but decided against it because it would only > >> show a single wait event. And wouldn't really describe spinlocks as a whole, > >> just the "extreme" delays. If we wanted to report the spin waits more > >> granular, we'd presumably have to fit the wait events into the lwlock, buffers > >> and some new category where we name individual spinlocks. > > > >+1 for making a group of individual names spin delays. > > Personally I'm not interested in doing that work, tbh. Oh, then I have no objection to the "as is" state, because it doesn't exclude the future improvements. But this is still my 2 cents though. ------ Regards, Alexander Korotkov
В списке pgsql-hackers по дате отправления: