Hmm.. also data such as what is the background writer currently doing, where
are we at in checkpoint segments, how close to checkpoint timeouts are we,
etc.
On 8/2/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
>
> Josh Tolley escribió:
> > On 8/2/07, Gavin M. Roy <gmr(at)myyearbook(dot)com> wrote:
> > > Are you contemplating providing access to data that's currently not
> stored
> > > in the pg_ catalog tables? I currently monitor the statio data,
> > > transactions per second, and active/idle backends. Things that I
> think
> > > would be useful would be average query execution time, longest
> execution
> > > time, etc. Other pie in the sky ideas would include current level of
> total
> > > bloat in a database, total size on disk of a database broken down by
> tables,
> > > indexes, etc.
> >
> > My own goal is to have pgsnmpd able, as much as possible, to fill the
> > same role the set of scripts an arbitrary PostgreSQL DBA sets up on a
> > typical production server. That includes statistics tables and catalog
> > tables, but certainly isn't limited to just that. So doing things like
> > categorizing total sessions in interesting and useful ways (for
> > instance, # of idle connections, # of active connections, max
> > transaction length, etc.) are certainly within pgsnmpd's purview.
>
> More ideas: autovacuum metrics, for example how long since the last
> vacuum of tables, age(pg_class.relfrozenxid), how many dead tuples there
> are, pg_class.relpages (do tables shrink, grow or stay constant-size?),
> etc.
>
> --
> Alvaro Herrera Developer,
> http://www.PostgreSQL.org/
> "La felicidad no es mañana. La felicidad es ahora"
>