On Fri, Jul 25, 2025 at 10:40 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Jul 21, 2025 at 7:49 PM Andres Freund <andres@anarazel.de> wrote:
> > 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.
>
> I'm not doubtful that this is a good idea. There are a number of
> tableams around these days that are "heap except whatever", where (I
> suspect) the size of "whatever" ranges from quite small to moderately
> large. I imagine that such efforts end up duplicating a lot of heapam
> code and probably always will; but if we can avoid increasing that
> amount, I think it's a good idea.
Based on our previous discussions, I have contemplated modifying the
patch to define the callback functions for parallel table vacuum
within a structure in vacuumparallel.c instead of using table AM's
callbacks. This approach would require the leader to pass both the
library name and handler function name to vacuumparallel.c, enabling
workers to locate the handler function via load_external_function()
and access the callback functions. Although it's technically feasible,
I'm not sure that the design is elegant; while table AM seeking to use
parallel index vacuuming can simply invoke parallel_vacuum_init(),
those requiring parallel table vacuum would need to both provide the
handler function and supply the library and handler function names.
An alternative, more straightforward approach would be to implement a
dedicated ParallelContext in vacuumlazy.c specifically for parallel
heap vacuum, distinct from the ParallelVacuumContext in
vacuumparallel.c. Under this design, vacuumparallel.c would be
exclusively dedicated to parallel index vacuuming, while the parallel
heap vacuum implementation would be contained within vacuumlazy.c,
eliminating the need for a handler function. While this solution seems
more elegant, it would result in code duplication between vacuumlazy.c
and vacuumparallel.c, particularly in areas concerning worker
initialization and cost-based delays.
At present, I am inclined toward the latter solution, though I have
yet to implement it. I welcome any feedback on these approaches.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
