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

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Дата
Msg-id CAPpHfds-+RQYeWrcOZzR24L+G9PvfLSBb01-Xpm+pBO=CoNpbg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Amit Kapila <amit.kapila16@gmail.com>)
Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
On Sun, Jan 31, 2016 at 6:55 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jan 28, 2016 at 9:16 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Jan 28, 2016 at 2:12 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Tue, Jan 26, 2016 at 3:10 AM, andres@anarazel.de <andres@anarazel.de> wrote:
> > > I do think there's a considerable benefit in improving the
> > > instrumentation here, but his strikes me as making live more complex for
> > > more users than it makes it easier. At the very least this should be
> > > split into two fields (type & what we're actually waiting on). I also
> > > strongly suspect we shouldn't use in band signaling ("process not
> > > waiting"), but rather make the field NULL if we're not waiting on
> > > anything.
> >
> > +1 for splitting it into two fields.
> >
>
> I will take care of this.
>

As discussed, I have added a new field wait_event_type along with
wait_event in pg_stat_activity.  Changed the code return NULL, if
backend is not waiting.  Updated the docs as well. 

I wonder if we can use 4-byte wait_event_info more efficiently. 
LWLock number in the tranche would be also useful information to expose. Using lwlock number user can determine if there is high concurrency for single lwlock in tranche or it is spread over multiple lwlocks.
I think it would be enough to have 6 bits for event class id and 10 bit for event id. So, it would be maximum 64 event classes and maximum 1024 events per class. These limits seem to be fair enough for me.
And then we save 16 bits for lock number. It's certainly not enough for some tranches. For instance, number of buffers could be easily more than 2^16. However, we could expose at least lower 16 bits. It would be at least something. Using this information user at least can make a conclusion like "It MIGHT be a high concurrency for single buffer content. Other way it is coincidence that a lot of different buffers have the same 16 lower bits.".

Any thoughts?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: extend pgbench expressions with functions
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Transactions involving multiple postgres foreign servers