Greetings,
* 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.
Thanks!
Stephen
