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  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: perform_spin_delay() vs wait events
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Re: Damage control for planner's get_actual_variable_endpoint() runaway