2014-08-18 7:42 GMT+02:00 Alvaro Herrera <alvhe...@2ndquadrant.com>: > Pavel Stehule wrote: > > 2014-08-13 15:22 GMT+02:00 MauMau <maumau...@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. >
surely it should be visible from all sessions and least 48 hours. I have no problem with cleaning pgstats after crash - it is cost related to minimal overhead. And on server related hw there are (should be) a minimal number of crash. Regards Pavel > > -- > Álvaro Herrera http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
