On Tue, Aug 15, 2017 at 12:45 PM, Alvaro Herrera
<alvherre@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
