On Mon, Jul 21, 2025 at 4:49 PM Andres Freund <and...@anarazel.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
