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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
