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

From Stephen Frost
Subject Re: log_autovacuum in Postgres 14 -- ordering issue
Date
Msg-id 20210825210722.GY17906@tamriel.snowman.net
Whole thread Raw
In response to Re: log_autovacuum in Postgres 14 -- ordering issue  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: log_autovacuum in Postgres 14 -- ordering issue  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Greetings,

* Peter Geoghegan (pg@bowt.ie) wrote:
> On Wed, Aug 25, 2021 at 11:42 AM Nikolay Samokhvalov
> <samokhvalov@gmail.com> wrote:
> > The last two lines are also "*** usage" -- shouldn't the buffer numbers be next to them?
>
> I agree that that would be better still -- but all the "usage" stuff
> together in one block.
>
> And that leads me to another observation: The track_io_timing stuff
> (also new to Postgres 14) might also need to be reordered. And maybe
> even the WAL usage stuff, which was added in Postgres 13.
>
> That way the overall structure starts with details of the physical
> data structures (the table and its indexes), then goes into buffers
>
> 1. Heap pages
> 2. Heap tuples
> 3. Index stuff
> 4. I/O timings (only when track_io_timing is on)
> 5. avg read rate (always)
> 6. buffer usage
> 7. WAL usage.
> 8. system usage
>
> This would mean that I'd be flipping the order of 7 and 8 relative to
> Postgres 13 -- meaning there'd be one difference between Postgres 14
> and some existing stable release. But I think that putting WAL usage
> last of all (after system usage) makes little sense -- commit
> b7ce6de93b shouldn't have done it that way. I always expect to see the
> getrusage() stuff last.

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.

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

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: log_autovacuum in Postgres 14 -- ordering issue
Next
From: Zhihong Yu
Date:
Subject: Re: Multi-Column List Partitioning