Re: proposal for 9.5: monitoring lock time for slow queries

2014-08-18 7:42 GMT+02:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:

> Pavel Stehule wrote:
> > 2014-08-13 15:22 GMT+02:00 MauMau <maumau307(at)gmail(dot)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
>