Re: More aggressive vacuuming of temporary tables
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-10-29T01:11:47Z
Lists: pgsql-hackers
Hi, On 2020-10-14 13:31:03 -0700, Andres Freund wrote: > I was thinking about this a bit more, and I think the answer might be to > use Min(latestCompletedXid, MyProc->xid). That would, as far as I can > tell, never miss something vacuumable in a temporary table, doesn't > require to know whether we're running as the top-level command. > > The reason for preferring latestCompletedXid over nextXid is that the > former is protected by ProcArrayLock and already accessed in > GetSnapshotData(), so we can cheaply compute the horizons as part of > pruning. > > I think that cannot miss something vacuumable in a temp table for VACUUM > because that would have to have been left over by an already completed > transaction (by us, before the VACUUM). > > In addition this allows HOT pruning etc on temp tables to be just as > aggressive as VACUUM is. > > I wrote a patch to do so for [1], but it seemed topically more relevant > here. Running tests in a loop, no failures after the first few > iterations. > > [1] https://postgr.es/m/20200921212003.wrizvknpkim2whzo%40alap3.anarazel.de Pushed this change in logic. The only "real" change is that the horizon for backends without an xid needs to be latestCompletedXid + 1, rather than just latestCompletedXid. The horizon indicates the oldest *non*-removable xid, and for temp tables latestCompletedXid can always be vacuumed when no xid is assigned. Greetings, Andres Freund
Commits
-
Centralize horizon determination for temp tables, fixing bug due to skew.
- 94bc27b57680 14.0 landed
-
Improve test coverage of ginvacuum.c.
- 4c51a2d1e4b7 14.0 landed
-
Set cutoff xmin more aggressively when vacuuming a temporary table.
- a7212be8b9e0 14.0 landed