Re: log_autovacuum in Postgres 14 -- ordering issue

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: log_autovacuum in Postgres 14 -- ordering issue
Date: 2021-08-27 19:30:48
Message-ID: 20210827193048.GM17906@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Peter Geoghegan (pg(at)bowt(dot)ie) wrote:
> On Fri, Aug 27, 2021 at 11:35 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > BTW, I noticed one thing about the track_io_time stuff. Sometimes it
> > > looks like this:
> > >
> > > I/O timings:
> > >
> > > i.e., it doesn't show anything at all after the colon.
>
> > Reporting zeros seems
> > valuable to me in that it shows that we did actually track the io timing
> > and there simply wasn't any time spent doing that- if we didn't include
> > the line at all then it wouldn't be clear if there wasn't any time spent
> > in i/o or if track io timing wasn't enabled.
>
> The principle that we don't show things that are all-zeroes is unique
> to text-format EXPLAIN output -- any other EXPLAIN format doesn't
> treat all-zeroes as a special case. And so the most consistent and
> correct thing seems to be this: show both all-zero "read:" and
> "write:" (both in vacuumlazy.c and in analyze.c), without making any
> other changes (i.e., no changes to EXPLAIN output are needed).

I suppose.

> You seem to be almost sold on that plan anyway. But this text format
> EXPLAIN rule seems like it decides the question for us.

I don't particularly care for that explain rule, ultimately, but it's
been around longer than I have and so I guess it wins. I'm fine with
always showing the read/write for VACUUM and ANALYZE.

Including 'ms' and lower-casing 'Timings' to 'timings' still strikes me
as something that should be consistent for all of these, but that's
independent of this and I'm not going to stress over it, particularly
since that's pre-existing.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-08-27 19:31:51 \dP and \dX use ::regclass without "pg_catalog."
Previous Message Andres Freund 2021-08-27 19:28:42 Re: [PATCH] Disable bgworkers during servers start in pg_upgrade