On Tue, Aug 15, 2017 at 12:45 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > I'm thinking that this data is useful to analyze as a stream of related > events, rather than as individual data points. Grepping logs in order to > extract the numbers is lame and slow. If you additionally have to mix > data that comes from vacuumdb with the autovacuum data from the server > log, that's much worse. Maybe you remember this thread? > https://www.postgresql.org/message-id/flat/509300F7.5000803%402ndQuadrant.com > I'm thinking it would be damn convenient to have both user-invoked > VACUUM and autovacuum emit some sort of event data which is saved > somewhere for later analysis.
Ah... A tracker for the history activity. With these kind of things there need to be a careful design to control data retention as events keep piling up. Yeah that would be useful to save CPU grepping for dedicated logs. And we could just have an API to a history table to which is sent a timestamp, an event name and an object like a JSON blob or a text array. The stats collector could do the cleanup of the oldest records by maintaining a counter to know the number of records it should keep around, defined by a GUC, or a duration to allow retention of history for this period, say the last X days of events. For vacuum logs, it would be possible to get things done with saving this information into a private memory area, and then offer a hook to let callers do what they want with this data... Not extensible and ugly, but that would do the work. Still I don't like that. -- Michael -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers