Re: Unifying VACUUM VERBOSE and log_autovacuum_min_duration output

From: Greg Stark <stark(at)mit(dot)edu>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Unifying VACUUM VERBOSE and log_autovacuum_min_duration output
Date: 2021-12-22 05:46:21
Message-ID: CAM-w4HM4ZQMPUYniaiFWm-oiSyBuuXO7+aigB8dP_54aCv9Ojg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I haven't read the patch yet. But some thoughts based on the posted output:

1) At first I was quite skeptical about losing the progress reporting.
I've often found it quite useful. But looking at the examples I'm
convinced.

Or rather I think a better way to look at it is that the progress
output for the operator should be separated from the metrics logged.
As an operator what I want to see is some progress indicator
""starting table scan", "overflow at x% of table scanned, starting
index scan", "processing index 1" "index 2"... so I can have some idea
of how much longer the vacuum will take and see whether I need to
raise maintenance_work_mem and by how much. I don't need to see all
the metrics while it's running.

2) I don't much like the format. I want to be able to parse the output
with awk or mtail or even just grep for relevant lines. Things like
"index scan not needed" make it hard to parse since you don't know
what it will look like if they are needed. I would have expected
something like "index scans: 0" which is actually already there up
above. I'm not clear how this line is meant to be read. Is it just
explaining *why* the index scan was skipped? It would just be missing
entirely if it wasn't skipped?

Fwiw, having it be parsable is why I wouldn't want it to be multiple
ereports. That would mean it could get interleaved with other errors
from other backends. That would be a disaster.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-12-22 05:54:52 Re: row filtering for logical replication
Previous Message Etsuro Fujita 2021-12-22 05:40:45 Re: postgres_fdw: incomplete subabort cleanup of connections used in async execution