Re: n_ins_since_vacuum stats for aborted transactions
Sami Imseih <samimseih@gmail.com>
From: Sami Imseih <samimseih@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>,
Euler Taveira <euler@eulerto.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-09T22:53:56Z
Lists: pgsql-hackers
> 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. Fair enough, and I think I got my answers from this thread. This design decision was not discussed in the thread for b07642dbcd8. So, I think public documentation updates to clarify that n_tup_upd|del|ins, and n_ins_since_vacuum include aborted rows is a good enhancement. Also a code comment in pgstat_relation_flush_cb that explains ins_since_vacuum intentionally includes aborted inserts. tabentry->ins_since_vacuum += lstats->counts.tuples_inserted; -- Sami Imseih
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