Re: Parallel heap vacuum

On Tue, Jan 21, 2025 at 11:05 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Sun, Jan 19, 2025 at 7:50 AM Tomas Vondra <tomas(at)vondra(dot)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