Re: RFC: replace pg_stat_activity.waiting with something more descriptive

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Дата
Msg-id CAB7nPqSpGjzNZXTyOQhNHH_JqPHCe73B93iNr74XphCx01RjwA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Vladimir Borodin <root@simply.name>)
Ответы Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Tue, Nov 17, 2015 at 8:36 PM, Vladimir Borodin <root@simply.name> wrote:
>
> 14 нояб. 2015 г., в 10:50, Amit Kapila <amit.kapila16@gmail.com> написал(а):
>
> On Wed, Sep 16, 2015 at 11:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Sep 16, 2015 at 12:29 PM, Alexander Korotkov
>> <aekorotkov@gmail.com> wrote:
>>
>> >> I think it's reasonable to consider reporting this data in the PGPROC
>> >> using a 4-byte integer rather than reporting it through a singe byte
>> >> in the backend status structure.  I believe that addresses the
>> >> concerns about reporting from auxiliary processes, and it also allows
>> >> a little more data to be reported.  For anything in excess of that, I
>> >> think we should think rather harder.  Most likely, such addition
>> >> detail should be reported only for certain types of wait events, or on
>> >> a delay, or something like that, so that the core mechanism remains
>> >> really, really fast.
>> >
>> > That sounds reasonable. There are many pending questions, but it seems
>> > like
>> > step forward to me.
>>
>> Great, let's do it.  I think we should probably do the work to
>> separate the non-individual lwlocks into tranches first, though.
>>
>
> One thing that occurred to me in this context is that if we store the wait
> event information in PGPROC, then can we think of providing the info
> about wait events in a separate view pg_stat_waits (or pg_stat_wait_info or
> any other better name) where we can display wait information about
> all-processes rather than only backends?  This will avoid the confusion
> about breaking the backward compatibility for the current 'waiting' column
> in pg_stat_activity.
>
> pg_stat_waits can have columns:
> pid  - Process Id
> wait_class_name - Name of the wait class
> wait class_event  - name of the wait event
>
> We can extend it later with the information about timing for wait event.
>
> Also, if we follow this approach, I think we don't need to store this
> information in PgBackendStatus.
>
>
> Sounds like exactly the same that was proposed by Ildus in this thead [0].
> Great to be thinking in the same direction. And on the rights of
> advertisements I’ve somehow described using all those views here [1].
>
> [0] http://www.postgresql.org/message-id/559D4729.9080704@postgrespro.ru
> [1] https://simply.name/pg-stat-wait.html

This thread has stalled a bit and is waiting for new patches for some
time now, hence I have switched it as "returned with feedback" on the
CF app.
--
Michael



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

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: Combining Aggregates
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pam auth - add rhost item