Re: parallel vacuum comments

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: parallel vacuum comments
Date: 2021-11-15 12:43:53
Message-ID: CAD21AoBcJs8amMjPUMbzU_kM0PTghMq5R+zhAexC-qa+ve924A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 15, 2021 at 8:04 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> 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.

Thanks for your clarification. I agreed.

I'll update an updated patch tomorrow.

Regards,

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message torikoshia 2021-11-15 12:59:15 Re: RFC: Logging plan of the running query
Previous Message osumi.takamichi@fujitsu.com 2021-11-15 12:13:35 RE: Failed transaction statistics to measure the logical replication progress