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 | CAPpHfdvDJzZDA8P7pxVFFKwv8995CjP5z10C8GgDM+Mtq10kAw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>) |
Ответы |
Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Список | pgsql-hackers |
On Thu, Aug 6, 2015 at 1:01 PM, Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru> wrote:
On 08/05/2015 09:33 PM, Robert Haas wrote:On Wed, Aug 5, 2015 at 1:10 PM, Ildus KurbangalievI see that now. Thank you for the point.
<i.kurbangaliev@postgrespro.ru> wrote:About `memcpy`, PgBackendStatus struct already have a bunch of multi-byteYou're missing the point. Those multi-byte fields have additional
variables, so it will be
not consistent anyway if somebody will want to copy it in that way. On the
other hand two bytes in this case
give less overhead because we can avoid the offset calculations. And as I've
mentioned before the class
of wait will be useful when monitoring of waits will be extended.
synchronization requirements, as I explained in some detail in my
previous email. You can't just wave that away.
I've looked deeper and I found PgBackendStatus to be not a suitable
place for keeping information about low level waits. Really, PgBackendStatus
is used to track high level information about backend. This is why auxiliary
processes don't have PgBackendStatus, because they don't have such information
to expose. But when we come to the low level wait events then auxiliary
processes are as useful for monitoring as backends are. WAL writer,
checkpointer, bgwriter etc are using LWLocks as well. This is certainly unclear
why they can't be monitored.
This is why I think we shoudn't place wait event into PgBackendStatus. It
could be placed into PGPROC or even separate data structure with different
concurrency model which would be most suitable for monitoring.
+1 for tracking wait events not only for backends
Ildus, could you do following?
1) Extract LWLocks refactoring into separate patch.
2) Make a patch with storing current wait event information in PGPROC.
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: