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 по дате отправления: