Re: Tracking wait event for latches

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Tracking wait event for latches
Дата
Msg-id CAB7nPqRwVCnLgthpB16THrs=1xQ1nOG95qOqG44ogMe6V=4W3Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Tracking wait event for latches  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Tracking wait event for latches  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, Sep 28, 2016 at 9:45 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Sep 28, 2016 at 8:38 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> So should I change back the patch to have only one argument for the
>> eventId, and guess classId from it?
>
> Why would you need to guess?

Incorrect wording from me perhaps? i just meant that processing needs
to know what is the classId coming for a specific eventId.

> But, yes, I think one argument is much preferable.

OK. Here is the wanted patch. I have reduced the routines of WaitLatch
& friends to use only one argument, and added what is the classId
associated with a given eventId in an array of multiple fields, giving
something like that:
+ const struct wait_event_entry WaitEventEntries[] = {
+   /* Activity */
+   {WAIT_ACTIVITY, "ArchiverMain"},
[...]

I have cleaned up as well the inclusions of pgstat.h that I added
previously. Patch is attached.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Speed up Clog Access by increasing CLOG buffers
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: PATCH: Exclude additional directories in pg_basebackup