On Fri, Nov 2, 2012 at 8:54 AM, Josh Berkus <josh@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?
