Re: Explicit relation name in VACUUM VERBOSE log

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Explicit relation name in VACUUM VERBOSE log
Date: 2017-08-15 05:16:04
Message-ID: CAB7nPqSWDY+HhBNOgaX=XAc3wJ6CNC1CNgbz-c8vnscrGyiN6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 15, 2017 at 12:45 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-08-15 05:16:40 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Previous Message Tom Lane 2017-08-15 04:56:46 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values