Greetings,
* Li, Yong (yoli@ebay.com) wrote:
> > On Mar 7, 2024, at 03:09, Stephen Frost <sfrost@snowman.net> wrote:
> > * Alvaro Herrera (alvherre@alvh.no-ip.org) wrote:
> >> I suppose this is important to do if we ever want to move SLRUs into
> >> shared buffers. However, I wonder about the extra time this adds to
> >> pg_upgrade. Is this something we should be concerned about? Is there
> >> any measurement/estimates to tell us how long this would be? Right now,
> >> if you use a cloning strategy for the data files, the upgrade should be
> >> pretty quick ... but the amount of data in pg_xact and pg_multixact
> >> could be massive, and the rewrite is likely to take considerable time.
> >
> > While I definitely agree that there should be some consideration of
> > this concern, it feels on-par with the visibility-map rewrite which was
> > done previously. Larger systems will likely have more to deal with than
> > smaller systems, but it's still a relatively small portion of the data
> > overall.
> >
> > The benefit of this change, beyond just the possibility of moving them
> > into shared buffers some day in the future, is that this would mean that
> > SLRUs will have checksums (if the cluster has them enabled). That
> > benefit strikes me as well worth the cost of the rewrite taking some
> > time and the minor loss of space due to the page header.
> >
> > Would it be useful to consider parallelizing this work? There's already
> > parts of pg_upgrade which can be parallelized and so this isn't,
> > hopefully, a big lift to add, but I'm not sure if there's enough work
> > being done here CPU-wise, compared to the amount of IO being done, to
> > have it make sense to run it in parallel. Might be worth looking into
> > though, at least, as disks have gotten to be quite fast.
>
> Thank Alvaro and Stephen for your thoughtful comments.
>
> I did a quick benchmark regarding pg_upgrade time, and here are the results.
> For clog, 2048 segments can host about 2 billion transactions, right at the limit for wraparound.
> That’s the maximum we can have. 2048 segments are also big for pg_multixact SLRUs.
>
> Therefore, on a modern hardware, in the worst case, pg_upgrade will run for 7 seconds longer.
Thanks for testing! That strikes me as perfectly reasonable and seems
unlikely that we'd get much benefit from parallelizing it, so I'd say it
makes sense to keep this code simple.
Thanks again!
Stephen