Re: parallel vacuum comments - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: parallel vacuum comments
Date
Msg-id CAD21AoBcJs8amMjPUMbzU_kM0PTghMq5R+zhAexC-qa+ve924A@mail.gmail.com
Whole thread Raw
In response to Re: parallel vacuum comments  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Mon, Nov 15, 2021 at 8:04 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Nov 15, 2021 at 2:01 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Thu, Nov 11, 2021 at 6:38 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Thu, Nov 11, 2021 at 8:11 AM Masahiko Sawada <sawada.mshk@gmail.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.

Thanks for your clarification. I agreed.

I'll update an updated patch tomorrow.

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Failed transaction statistics to measure the logical replication progress
Next
From: torikoshia
Date:
Subject: Re: RFC: Logging plan of the running query