Greetings, * Alvaro Herrera (alvhe...@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
signature.asc
Description: PGP signature