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/
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 |