On Fri, Nov 2, 2012 at 8:54 AM, Josh Berkus <j...@agliodbs.com> wrote:
> Greg, > > First off, let me again praise the great work you and Peter are doing in > this area. > > Modeling this on pg_stat_statements includes the hope of packaging it as > > an extension with minor core hooks, and the idea that there would be a > > fixed size list of timing events available at any time. Consider it a > > FIFO queue built using a circular buffer. Dump events into there and > > provide a way to view them. If some fall out before they're > > analyzed/saved, that doesn't seem a problem for now. > > Agreed. > > > If you want 100% > > durable, the log is still available. Eventually I'd like a consumer for > > these that wrote them to a history table as an option, but that seems a > > second priority after getting them into memory in the first place. > > Yes, and easy for users/tools to implement once the basic data is out > there. > > > I'd > > like that consumer thing for pg_stat_statements too, but so far we're > > getting by without it. It seems like something that might benefit from > > the in-core queuing work one day too. > > Well, we could actually use such a thing in general, and not just for > the timing events. For example, it would be really useful to be able to > see, for example, pg_stat_user_tables from 2 days ago to estimate table > growth and activity, or pg_stat_replication from 10 minutes ago to > average replication lag. There was a plug-in tool for this, I think > Itagaki developed it. Anyone remember what/where it is? > pg_statsinfo perhaps? It is used for stat info management: http://pgfoundry.org/projects/pgstatsinfo/ -- Michael Paquier http://michael.otacoo.com
