Re: n_ins_since_vacuum stats for aborted transactions
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
Euler Taveira <euler@eulerto.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-09T19:58:32Z
Lists: pgsql-hackers
> The issue I see is that n_ins_since_vacuum should only > reflect the number of newly inserted rows that are eligible for > freezing, as described > in pgstat_report_vacuum [0] > > [0] > https://github.com/postgres/postgres/blob/master/src/backend/utils/activity/pgstat_relation.c#L238-L247 For the archives, that paragraph reads: /* * It is quite possible that a non-aggressive VACUUM ended up skipping * various pages, however, we'll zero the insert counter here regardless. * It's currently used only to track when we need to perform an "insert" * autovacuum, which are mainly intended to freeze newly inserted tuples. * Zeroing this may just mean we'll not try to vacuum the table again * until enough tuples have been inserted to trigger another insert * autovacuum. An anti-wraparound autovacuum will catch any persistent * stragglers. */ What work do you believe the word "mainly" does in that paragraph? The presence of the word "mainly" rather than "only" somewhat cuts against your argument that we should only be counting tuples that get inserted without aborting. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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