On Fri, Mar 13, 2026 at 10:39:52AM +0800, Xuneng Zhou wrote: > Thanks for fixing this and for taking the time to review and test > the patches.
Looking at the rest, I have produced some numbers: pgstattuple_small (20k tuples, io_uring) base= 60839.9ms patch=10949.9ms 5.56x ( 82.0%) (reads=4139->260, io_time=49616.97->55.25ms) pgstattuple_small (20k tuples, worker=3) base= 60577.5ms patch=11470.0ms 5.28x ( 81.1%) (reads=4139->260, io_time=49359.79->69.60ms) hash_vacuum (1M tuples, io_uring) base=199929.0ms patch=161747.0ms 1.24x ( 19.1%) (reads=4665->1615, io_time=47084.8->9925.77ms) hash_vacuum (1M tuples, worker=12) base=203417.0ms patch=161687.0ms 1.26x ( 20.5%) (reads=4665->1615, io_time=48356.3->9917.24ms) The hash vacuum numbers are less amazing here than yours. Trying out various configurations does not change the results much (I was puzzled for a couple of hours that I did not see any performance impact but forgot the eviction of the index pages from the shared buffers, that influences the numbers to what I have here), but I'll take it anyway. One thing that I was wondering for the pgstattuple patch is if we should have "scanned" put outside the private data of the callback as we get back to the main loop once we know that the page is not all-visible, so we could increment the counter in the main loop instead of the callback. Now I get that you have done that as it feels cleaner for the "default" return path of the callback, while the logic remains the same, so I have kept it as-is at the end, tweaked a few things, and applied this one. I have not been able to review yet the patch for the hash VACUUM proposal, which would be the last one. -- Michael
signature.asc
Description: PGP signature
