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.
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.
