Re: Parallel heap vacuum

On Fri, Mar 7, 2025 at 10:41 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> I've attached the updated version patches.

When testing the multi passes of table vacuuming, I found an issue.
With the current patch, both leader and parallel workers process stop
the phase 1 as soon as the shared TidStore size reaches to the limit,
and then the leader resumes the parallel heap scan after heap
vacuuming and index vacuuming. Therefore, as I described in the patch,
one tricky part of this patch is that it's possible that we launch
fewer workers than the previous time when resuming phase 1 after phase
2 and 3. In this case, since the previous parallel workers might have
already allocated some blocks in their chunk, newly launched workers
need to take over their parallel scan state. That's why in the patch
we store workers' ParallelBlockTableScanWorkerData in shared memory.
However, I found my assumption is wrong; in order to take over the
previous scan state properly we need to take over not only
ParallelBlockTableScanWorkerData but also ReadStream data as parallel
workers might have already queued some blocks for look-ahead in their
ReadStream. Looking at ReadStream codes, I find that it's not
realistic to store it into the shared memory.

One plausible solution would be that we don't use ReadStream in
parallel heap vacuum cases but directly use
table_block_parallelscan_xxx() instead. It works but we end up having
two different scan methods for parallel and non-parallel lazy heap
scan. I've implemented this idea in the attached v12 patches.

Other than the above change, I've fixed some bugs and addressed review
comments I got so far.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com