On Sun, Apr 18, 2021 at 04:27:15PM -0700, Peter Geoghegan wrote: > Everybody tends to talk about HOT as if it works perfectly once you > make some modest assumptions, such as "there are no long-running > transactions", and "no UPDATEs will logically modify indexed columns". > But I tend to doubt that that's truly the case -- I think that there > are still pathological cases where HOT cannot keep the total table > size stable in the long run due to subtle effects that eventually > aggregate into significant issues, like heap fragmentation. Ask Jan > Wieck about the stability of some of the TPC-C/BenchmarkSQL tables to
... > We might have successfully fit the successor heap tuple version a > million times before just by HOT pruning, and yet currently we give up > just because it didn't work on the one millionth and first occasion -- > don't you think that's kind of silly? We may be able to afford having > a fallback strategy that is relatively expensive, provided it is > rarely used. And it might be very effective in the aggregate, despite > being rarely used -- it might provide us just what we were missing > before. Just try harder when you run into a problem every once in a > blue moon! > > A diversity of strategies with fallback behavior is sometimes the best > strategy. Don't underestimate the contribution of rare and seemingly > insignificant adverse events. Consider the lifecycle of the data over That is an intersting point --- we often focus on optimizing frequent operations, but preventing rare but expensive-in-aggregate events from happening is also useful. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.