On Thu, Aug 24, 2017 at 11:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
>> Michael Paquier wrote:
>>> Hm. I am not sure what you have in mind here.
>> 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.
> Yes.  And there is a bigger issue here, which is that the output of
> VACUUM VERBOSE is meant to be sent to the client for *human* readability.
> (As you noted, INFO-level messages don't normally go to the server log
> in the first place, and that's not by accident.)  Repeating the full table
> name in every line will be really annoying for that primary use-case.
> I am not sure what we want to do to address Masahiko-san's use-case, but
> ideally his workflow wouldn't involve log-scraping at all.

The use-case I had is that I run vacuumdb *without -j option* and save
all verbose logs into a text file, and then checking it later. I said
vacuumdb with -j option before but it was wrong. It cannot happen two
vacuum verbose logs are emitted mixed together even if -j option is

I sometimes search a particular table/index from the logs but also in
that case it was hard to distinguish logs. This is still not primary
case though.


Masahiko Sawada
NTT Open Source Software Center

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to