On Fri, Jul 28, 2023 at 5:03 PM Melanie Plageman <melanieplage...@gmail.com> wrote: > When you were working on this, what were the downsides of only having the > criteria that 1) page would be all_visible/all_frozen and 2) we did prune > something (i.e. no consideration of FPIs)?
Conditioning freezing on "all_visible && all_frozen" seems likely to always be a good idea when it comes to any sort of speculative trigger criteria. Most of the wins in this area will come from avoiding future FPIs, and you can't hope to do that unless you freeze everything on the page. The cost of freezing when "all_visible && all_frozen" does not hold may be quite low, but the benefits will also be very low. Also, the way that recovery conflicts are generated for freeze records somewhat depends on this right now -- though you could probably fix that if you had to. Note that we *don't* really limit ourselves to cases where an FPI was generated from pruning, exactly -- even on 16. With page-level checksums we can also generate an FPI just to set a hint bit. That triggers freezing too, even on insert-only tables (assuming checksums are enabled). I expect that that will be an important condition for triggering freezing in practice. Your question about 2 seems equivalent to "why not just always freeze?". I don't think that that's a bad question -- quite the opposite. Even trying to give an answer to this question would amount to getting involved in new work on VACUUM, though. So I don't think I can help you here. -- Peter Geoghegan