Re: log_autovacuum in Postgres 14 -- ordering issue

Greetings,

* Peter Geoghegan (pg(at)bowt(dot)ie) wrote:
> On Wed, Aug 25, 2021 at 2:07 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > I generally like the idea though I'm not sure about changing things in
> > v13 as there's likely code out there that's already parsing that data
> > and it might suddenly break if this was changed.
>
> Agreed -- I won't backpatch anything to v13.

Ok.

> > Given that such code would need to be adjusted for v14 anyway, I don't
> > really see changing it in v14 as as being an issue (nor do I feel that
> > it's even a big concern at this point in the release cycle, though
> > perhaps others feel differently).
>
> 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. This happens
> because the instrumentation indicates that no time was spent on either
> read I/O or write I/O.

Hrmpf. That's an interesting point.

> I now wonder if we should just unconditionally report both things
> (both "read:" and "write:"), without regard for whether or not they're
> non-zero. (We'd do the same thing with ANALYZE's equivalent code too,
> if we actually did this -- same issue there.)

So, it was done that way to match how we report I/O Timings from explain
analyze, around src/backend/commands/explain.c:3574 (which I note is now
slightly different from what VACUUM/ANALYZE do due to f4f4a64...). The
intent was to be consistent in all of these places and I generally still
feel that's a worthwhile thing to strive for.

I don't have any particular problem with just always reporting it. Sure
looks odd to have the line there w/o anything after it. Perhaps we
should also address that in the explain analyze case though, and make
the same changes there that were done in f4f4a64? 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.

Thanks,

Stephen