On Fri, Feb 25, 2022 at 3:48 PM Andres Freund <and...@anarazel.de> wrote: > I don't see why it matters that OldestXmin and OldestMxact are computed at the > same time? It's a question of the workload, not vacuum algorithm.
I think it's both. > OldestMxact inherently lags OldestXmin. OldestMxact can only advance after all > members are older than OldestXmin (not quite true, but that's the bound), and > they have always more than one member. > > > > How many of these "skewed MultiXacts" can we really expect? > > I don't think they're skewed in any way. It's a fundamental aspect of > multixacts. Having this happen to some degree is fundamental to MultiXacts, sure. But also seems like the approach of using FreezeLimit and MultiXactCutoff in the way that we do right now seems like it might make the problem a lot worse. Because they're completely meaningless cutoffs. They are magic numbers that have no relationship whatsoever to each other. There are problems with assuming that OldestXmin and OldestMxact "align" -- no question. But at least it's approximately true -- which is a start. They are at least not arbitrarily, unpredictably different, like FreezeLimit and MultiXactCutoff are, and always will be. I think that that's a meaningful and useful distinction. I am okay with making the most pessimistic possible assumptions about how any changes to how we freeze might cause FreezeMultiXactId() to allocate more MultiXacts than before. And I accept that the patch series shouldn't "get credit" for "offsetting" any problem like that by making relminmxid advancement occur much more frequently (even though that does seem very valuable). All I'm really saying is this: in general, there are probably quite a few opportunities for FreezeMultiXactId() to avoid allocating new XMIDs (just to freeze XIDs) by having the full context. And maybe by making the dialog between lazy_scan_prune and heap_prepare_freeze_tuple a bit more nuanced. -- Peter Geoghegan
