Re: parallel vacuum comments

On Mon, Nov 15, 2021 at 2:01 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Thu, Nov 11, 2021 at 6:38 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Thu, Nov 11, 2021 at 8:11 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >
> > > I've attached a draft patch that refactors parallel vacuum and
> > > separates parallel-vacuum-related code to new file vacuumparallel.c.
> > > After discussion, I'll divide the patch into logical chunks.
> > >
> > > What I'm not convinced yet in this patch is that vacuum.c,
> > > vacuumlazy.c and vacuumparallel.c depend on the data structure to
> > > store dead tuples (now called VacDeadTuples, was LVDeadTuples). I
> > > thought that it might be better to separate it so that a table AM can
> > > use another type of data structure to store dead tuples. But since I
> > > think it may bring complexity, currently a table AM has to use
> > > VacDeadTuples in order to use the parallel vacuum.
> > >
> >
> > I think it might be better to attempt doing anything to make it
> > generic for tableAM in a separate patch if that is required.
>
> You mean to refactor relation_vacuum table AM API too? Currently,
> relation_vacuum API is responsible for whole vacuum operation and
> there is no room for the core doing anything during vacuum. So
> probably it doesn’t make sense to have a table AM API for parallel
> vacuum.
>

No, I intend to say that let's not do anything for it as of now. It is
not clear what a generic structure for it should be and whether AM's
need anything like that. As the current structure is specific to heap,
it might make sense to declare it in heapam.h as we are doing for
function heap_vacuum_rel(), and additionally, you might want to
include heap in that structure name to be more explicit.

--
With Regards,
Amit Kapila.