Re: proposal for 9.5: monitoring lock time for slow queries
От | Alvaro Herrera |
---|---|
Тема | Re: proposal for 9.5: monitoring lock time for slow queries |
Дата | |
Msg-id | 20140818054219.GB8062@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: proposal for 9.5: monitoring lock time for slow queries (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: proposal for 9.5: monitoring lock time for slow queries
Re: proposal for 9.5: monitoring lock time for slow queries |
Список | pgsql-hackers |
Pavel Stehule wrote: > 2014-08-13 15:22 GMT+02:00 MauMau <maumau307@gmail.com>: > > I didn't mean performance statistics data to be stored in database tables. > > I just meant: > > > > * pg_stat_system_events is a view to show data on memory, which returns > > one row for each event across the system. This is similar to > > V$SYSTEM_EVENT in Oracle. > > > > * pg_stat_session_events is a view to show data on memory, which returns > > one row for each event on one session. This is similar to V$SESSION_EVENT > > in Oracle. > > > > * The above views represent the current accumulated data like other > > pg_stat_xxx views. > > > > * EXPLAIN ANALYZE and auto_explain shows all events for one query. The > > lock waits you are trying to record in the server log is one of the events. > > I am little bit sceptic about only memory based structure. Is it this > concept acceptable for commiters? Is this supposed to be session-local data, or is it visible from remote sessions too? How durable is it supposed to be? Keep in mind that in case of a crash, all pgstats data is erased. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: