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-WzmHXS3mDb+DCDYOZ5GOuoA4M6A4DtuxKUdjZ4dESG-sdQ@mail.gmail.com
Whole thread Raw
In response to Re: log_autovacuum in Postgres 14 -- ordering issue  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Wed, Aug 25, 2021 at 5:23 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Ooh, this was illuminating -- thanks for explaining.  TBH I would have
> been very confused if asked to explain what that log line meant; and now
> that I know what it means, I am even more convinced that we need to work
> harder at it :-)
>
> I'll see if I can come up with something ...

BTW, I wonder if you need to reconsider
PROGRESS_VACUUM_NUM_DEAD_TUPLES in light of all this. It actually
counts LP_DEAD items, which aren't really dead tuples. As my example
shows, the distinction between "tuples removed" (as this log output
refers to them) and LP_DEAD items removed from heap pages can be very
important.

One way of handling this might be to call LP_DEAD items "items removed
from indexes" -- "tuples removed" can be treated as "items removed
from table". Or something along those lines, at least. This is how I
phrase it in certain vacuumlazy.c source code comments already. It's
not 100% accurate, but in a way it's a lot closer to the truth. And it
allows you to sidestep the issue with PROGRESS_VACUUM_NUM_DEAD_TUPLES
by only slightly redefining what that means to users -- it can be
recast as information about index tuples specifically (there may not
actually be any matching index tuples, especially in Postgres 14, but
that isn't worth getting in to in user docs IMV).

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: archive status ".ready" files may be created too early
Next
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER