On Thu, Dec 29, 2022 at 12:50 PM Peter Geoghegan <p...@bowt.ie> wrote: > 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.
> 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. Attached patch shows what I mean here. I think that there is a tendency for OldestMxact to be held back by a disproportionate amount (relative to OldestXmin) in the presence of long running transactions and concurrent updates from short-ish transactions. The way that we maintain state in shared memory to compute OldestMxact (OldestMemberMXactId/OldestVisibleMXactId) seems to be vulnerable to that kind of thing. I'm thinking of scenarios where MultiXactIdSetOldestVisible() gets called from a long-running xact, at the first point that it examines any multi, just to read something. That effectively makes the long-running xact hold back OldestMxact, even when it doesn't hold back OldestXmin. A read-only transaction that runs in READ COMMITTED could do this -- it'll call OldestVisibleMXactId() and "lock in" the oldest visible Multi that it needs to continue to see as running, without clearing that until much later (until AtEOXact_MultiXact() is called at xact commit/abort). And without doing anything to hold back OldestXmin by the same amount, or for the same duration. That's the kind of scenario that the patch might make a difference in -- because it exploits the fact that OldestXmin can be a lot less vulnerable than OldestMxact is to being held back by long running xacts. Does that seem plausible to you? -- Peter Geoghegan
0001-Prefer-FRM_INVALIDATE_XMAX-over-FRM_NOOP-when-cheape.patch
Description: Binary data