Re: n_ins_since_vacuum stats for aborted transactions - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: n_ins_since_vacuum stats for aborted transactions
Date
Msg-id CAHgHdKsjGkrdpjZxmfOYxuvhBDrBK48T9bMKmb-6Pj38NiLYXA@mail.gmail.com
Whole thread Raw
In response to Re: n_ins_since_vacuum stats for aborted transactions  (Sami Imseih <samimseih@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: n_ins_since_vacuum stats for aborted transactions
Next
From: "David G. Johnston"
Date:
Subject: Re: n_ins_since_vacuum stats for aborted transactions