On Tue, Jan 21, 2025 at 11:05 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Sun, Jan 19, 2025 at 7:50 AM Tomas Vondra <to...@vondra.me> wrote: > > > > Hi, > > > > Thanks for the new patches. I've repeated my benchmarking on v8, and I > > agree this looks fine - the speedups are reasonable and match what I'd > > expect on this hardware. I don't see any suspicious results like with > > the earlier patches, where it got much faster thanks to the absence of > > SKIP_PAGE_THRESHOLD logic. > > > > Attached is the benchmarking script, CSV with raw results, and then also > > two PDF reports comparing visualizing the impact of the patch by > > comparing it to current master. > > > > * parallel-vacuum-duration.pdf - Duration of the vacuum, and duration > > relative to master (green - faster, read - slower). The patch is clearly > > an improvement, with speedup up to ~3x depending on the index count and > > a fraction of updated rows. > > > > * parallel-vacuum-reads.pdf - Average read speed, as reported by VACUUM > > VERBOSE. With the patch it can reach up to ~3GB/s, which is about the > > max value possible on this hardware - so that's nice. I'll try to test > > this on a better storage, to see how far it can go. > > Thank you for doing a performance benchmark. These results make sense to me. > > > I haven't done any actual code review on the new patches, I'll try to > > find time for that sometime next week. > > Thank you!
Since we introduced the eagar vacuum scan (052026c9b9), I need to update the parallel heap vacuum patch. After thinking of how to integrate these two features, I find some complexities. The region size used by eager vacuum scan and the chunk size used by parallel table scan are different. While the region is fixed size the chunk becomes smaller as we scan the table. A chunk of the table that a parallel vacuum worker took could be across different regions or be within one region, and different parallel heap vacuum workers might scan the same region. And parallel heap vacuum workers could be scanning different regions of the table simultaneously. During eager vacuum scan, we reset the eager_scan_remaining_fails counter when we start to scan the new region. So if we want to make parallel heap vacuum behaves exactly the same way as the single-progress vacuum in terms of the eager vacuum scan, we would need to have the eager_scan_remaining_fails counters for each region so that the workers can decrement it corresponding to the region of the block that the worker is scanning. But I'm concerned that it makes the logic very complex. I'd like to avoid making newly introduced codes more complex by adding yet another new code on top of that. Another idea is to disable the eager vacuum scan when parallel heap vacuum is enabled. It might look like just avoiding difficult things but it could make sense in a sense. The eager vacuum scan is aimed to amortize the aggressive vacuum by incrementally freezing pages that are potentially frozen by the next aggressive vacuum. On the other hand, parallel heap vacuum is available only in manual VACUUM and would be used to remove garbage on a large table as soon as possible or to freeze the entire table to avoid reaching the XID limit. So I think it might make sense to disable the eager vacuum scan when parallel vacuum. Thoughts? Thoughts? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
