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 20210825203305.GW17906@tamriel.snowman.net
Whole thread Raw
In response to log_autovacuum in Postgres 14 -- ordering issue  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: log_autovacuum in Postgres 14 -- ordering issue
List pgsql-hackers
Greetings,

* Peter Geoghegan (pg@bowt.ie) wrote:
> log_autovacuum output looks like this (as of Postgres 14):
>
> LOG:  automatic vacuum of table "regression.public.bmsql_order_line":
> index scans: 1
> pages: 0 removed, 8810377 remain, 0 skipped due to pins, 3044924 frozen
> tuples: 16819838 removed, 576364686 remain, 2207444 are dead but not
> yet removable, oldest xmin: 88197949
> buffer usage: 174505 hits, 7630386 misses, 5628271 dirtied
> index scan needed: 1959301 pages from table (22.24% of total) had
> 11745226 dead item identifiers removed
> index "bmsql_order_line_pkey": pages: 2380261 in total, 0 newly
> deleted, 0 currently deleted, 0 reusable
> avg read rate: 65.621 MB/s, avg write rate: 48.403 MB/s
> I/O timings: read: 65813.666 ms, write: 11310.689 ms
> system usage: CPU: user: 72.55 s, system: 52.07 s, elapsed: 908.42 s
> WAL usage: 7387358 records, 4051205 full page images, 28472185998 bytes
>
> I think that this output is slightly misleading. I'm concerned about
> the specific order of the lines here: the "buffer usage" line comes
> after the information that applies specifically to the heap structure,
> but before the information about indexes. This is the case despite the
> fact that its output applies to all buffers (not just those for the
> heap structure).
>
> It would be a lot clearer if the "buffer usage" line was simply moved
> down. I think that it should appear after the lines that are specific
> to the table's indexes -- just before the "avg read rate" line. That
> way we'd group the buffer usage output with all of the other I/O
> related output that summarizes the VACUUM operation as a whole.
>
> I propose changing the ordering along those lines, and backpatching
> the change to Postgres 14.

I don't have any particular issue with moving them.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: badly calculated width of emoji in psql
Next
From: Peter Geoghegan
Date:
Subject: Re: log_autovacuum in Postgres 14 -- ordering issue