Re: Parallel heap vacuum

On Mon, Jul 21, 2025 at 4:49 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2025-07-21 12:41:49 -0700, Masahiko Sawada wrote:
> > The reason why I added some callbacks as table AM callbacks in the
> > patch is that I could not find other better places. Currently,
> > vacuumparallel.c handles several critical operations for parallel
> > vacuuming: allocating and initializing DSM space for parallel index
> > vacuuming, initializing and launching parallel workers, and managing
> > various auxiliary tasks such as configuring vacuum delays and setting
> > maintenance_work_mem for workers. Given these existing
> > functionalities, I aimed to implement the parallel heap vacuum worker
> > launch through the same vacuumparallel.c codebase, maintaining a
> > consistent interface. To achieve this integration, vacuumparallel.c
> > requires access to heap-specific functions, and defining them as table
> > AM callbacks emerged as the cleanest solution.
>
> I don't think that can be the right solution. Vacuuming is a table-am specific
> operation and thus already happens within a table-am's own code. It would be
> rather wrong to have tableam.h indirected calls below heapam specific code.
>
> That is not to say you can't have callbacks or such, it just doesn't make
> sense for those callbacks to be at the level of tableam. If you want to make
> vacuumparallel support parallel table vacuuming for multiple table AMs (I'm
> somewhat doubtful that's a good idea), you could do that by having a
> vacuumparallel.c specific callback struct.

Thank you for the comments!

Do you think it makes sense to implement the above idea that we launch
parallel vacuum workers for heap through the same vacuumparallel.c
codebase and maintain the consistent interface with parallel index
vacuuming APIs?

I've considered an idea of implementing parallel heap vacuum
independent of vacuumparallel.c, but I find some difficulties and
duplications. For instance, vacuumparallel.c already does many
operations like initializing DSM space, setting vacuum delays, and
launching parallel vacuum workers. Probably we can expose
ParallelVacuumContext so that vacuumlazy.c can use it to launch
parallel workers for heap vacuuming, but I'm not sure it's a good
idea. We also need to expose other works that vacuumparallel.c does
such as setting ring_buffer size and cost-based vacuum delay too and
vacuumlazy.c needs to use them appropriately.

Regards,

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