Re: log_autovacuum in Postgres 14 -- ordering issue - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: log_autovacuum in Postgres 14 -- ordering issue
Date
Msg-id CAH2-WznW0FNxSVQMSRazAMYNfZ6DR_gr5WE78hc6E1CBkkJpzw@mail.gmail.com
Whole thread Raw
In response to Re: log_autovacuum in Postgres 14 -- ordering issue  (Stephen Frost <sfrost@snowman.net>)
Responses Re: log_autovacuum in Postgres 14 -- ordering issue  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Wed, Aug 25, 2021 at 2:07 PM Stephen Frost <sfrost@snowman.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.

> 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.

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.)

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fwd: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Estimating HugePages Requirements?