Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches) |
Дата | |
Msg-id | d0baf7ce-ae76-9c89-5c78-a04c0bf51156@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches) (Kuntal Ghosh <kuntalghosh.2007@gmail.com>) |
Ответы |
Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches) |
Список | pgsql-hackers |
Perhaps I'm confused by the title of this thread/CF entry, but background workers already do show up in pg_stat_activity. (You can verify that by testing the background sessions patch.) So which additional things are we aiming to see with this? In practice, I think it's common to do a quick select * from pg_stat_activity to determine whether a database instance is in use. (You always see your own session, but that's easy to eyeball.) If we add all the various background processes by default, that will make things harder, especially if there is no straightforward way to filter them out. Perhaps a pg_stat_user_* and pg_stat_system_* split like we have for some of the statistics tables would be useful? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: