On Thu, Aug 24, 2017 at 11:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@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
specified.
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.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center