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
