Re: More aggressive vacuuming of temporary tables
От | Andres Freund |
---|---|
Тема | Re: More aggressive vacuuming of temporary tables |
Дата | |
Msg-id | 20201029011147.b5dbua3m4mdk42op@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: More aggressive vacuuming of temporary tables (Andres Freund <andres@anarazel.de>) |
Список | 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
В списке pgsql-hackers по дате отправления: