On Tue, 2018-04-17 at 15:09 -0400, Tom Lane wrote: > Alvaro Herrera <[email protected]> writes: > > Andres was working on a radix tree structure to fix this problem, but > > that seems to be abandoned now, and it seems a major undertaking. While > > I agree that the proposed solution is a wart, it seems much better than > > no solution at all. Can we consider Fujii's proposal as a temporary > > measure until we fix shared buffers? I'm +1 on it myself. > > Once we've introduced a user-visible reloption it's going to be > practically impossible to get rid of it, so I'm -1. I'd much rather > see somebody put some effort into the radix-tree idea than introduce > a kluge that we'll be stuck with, and that doesn't even provide a > good user experience. Disabling vacuum truncation is *not* something > that I think we should recommend.
This new option would not only mitigate the long shared_buffers scan, it would also get rid of the replication conflict caused by the AccessExclusiveLock taken during truncation, which is discussed in https://www.postgresql.org/message-id/c9374921e50a5e8fb1ecf04eb8c6ebc3%40postgrespro.ru and seems to be a more difficult problem than anticipated. Could that tip the scales in favor of this stop-gap? FWIW, I have always considered heap truncation on VACUUM to be something strange anyway. VACUUM does not get rid of empty pages in the middle of a relation, so why is it so important to do it at the end of the relation? If the answer is "just because we can do it easily", then I think it would be ok to disable the feature in cases where it causes problems. Yours, Laurenz Albe
