On Thu, Dec 29, 2022 at 12:20 PM Peter Geoghegan <p...@bowt.ie> wrote: > > It seems somewhat wrong that we discard all the work that > > heap_prepare_freeze_tuple() did. Yes, we force freezing to actually happen > > in > > a bunch of important cases (e.g. creating a new multixact), but even so, > > e.g. GetMultiXactIdMembers() is awfully expensive to do for nought. Nor is > > just creating the freeze plan free. > > I'm not sure what you mean by that. I believe that the page-level > freezing changes do not allow FreezeMultiXactId() to call > GetMultiXactIdMembers() any more often than before. Are you concerned > about a regression, or something more general than that?
Here's an idea that seems like it could ameliorate the issue: When we're looping through members from GetMultiXactIdMembers(), and seeing if we can get away with !need_replace/FRM_NOOP processing, why not also check if there are any XIDs >= OldestXmin among the members? If not (if they're all < OldestXmin), then we should prefer to go further with processing the Multi now -- FRM_NOOP processing isn't actually cheaper. We'll already know that a second pass over the multi really isn't expensive. And that it will actually result in FRM_INVALIDATE_XMAX processing, which is ideal. Avoiding a second pass is really just about avoiding FRM_RETURN_IS_MULTI (and avoiding FRM_RETURN_IS_XID, perhaps, though to a much lesser degree). -- Peter Geoghegan
