Re: Is heap_page_prune() stats collector accounting wrong?
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-11-12T20:42:24Z
Lists: pgsql-hackers
Attachments
- v1-0001-Clear-up-ndeleted-pgstats-accounting.patch (application/octet-stream) patch v1-0001
On Fri, Nov 12, 2021 at 11:29 AM Peter Geoghegan <pg@bowt.ie> wrote: > We compensate here precisely because we are not running in VACUUM (it > has to be an opportunistic prune in practice). > If we're not running in VACUUM, and have to make a statistics > collector call, then we don't want to forget about DEAD tuples that > were pruned-away (i.e. no longer have tuple storage) when they still > have an LP_DEAD stub item. There is obviously no justification for > just ignoring LP_DEAD items there, because we don't know when VACUUM > is going to run next (since we are not VACUUM). Attached patch clears this up by adding some comments. It also moves the call to pgstat_update_heap_dead_tuples() from heap_page_prune() to heap_page_prune_opt(), which feels like a better place for it to me. -- Peter Geoghegan
Commits
-
Explain pruning pgstats accounting subtleties.
- b0f7425ec244 15.0 landed