Re: n_ins_since_vacuum stats for aborted transactions
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>,
Euler Taveira <euler@eulerto.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-09T22:30:18Z
Lists: pgsql-hackers
On Wednesday, April 9, 2025, Sami Imseih <samimseih@gmail.com> wrote: > > > What is the use case for that behavior? Perhaps you have one, but until > you make it explicit, it is hard for others to get behind your proposal. > > The point is to ensure that the pg_stats fields that autovacuum uses > are supplied the correct values > for the different thresholds they need to calculate, as described here [0] > > > [0] https://www.postgresql.org/message-id/CAA5RZ0uDyGW1omWqWkxyW8NB1qzsK > mXhnoMtzTBeRzSd4DMatQ%40mail.gmail.com > > Except there isn’t some singular provably correct value here. Today’s behavior (considering dead tuples) is not intrinsically wrong nor correct, and neither is what you propose (ignoring the dead tuples). The fact that those dead tuples get removed regardless is a point in favor of counting them when deciding what to do. And it’s also the long-standing behavior. You need to make a compelling argument to change to your preference. Inserting aborted dead tuples moves the counter closer to both autovacuum thresholds. There is no reason why that should be prohibited. I can see the argument for why one threshold should be dead tuples only and the other live tuples only - but I don’t favor that design. David J.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add code comment explaining ins_since_vacuum and aborted inserts
- 530050d8d285 18.0 landed
-
Trigger autovacuum based on number of INSERTs
- b07642dbcd8d 13.0 cited