Re: parallel vacuum comments
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Peter Geoghegan <pg@bowt.ie>
Date: 2021-11-15T12:43:53Z
Lists: 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/
Commits
-
Move parallel vacuum code to vacuumparallel.c.
- 8e1fae193864 15.0 landed
-
Move index vacuum routines to vacuum.c.
- cc8b25712b5e 15.0 landed
-
Improve parallel vacuum implementation.
- 22bd3cbe0c28 15.0 landed
-
Fix parallel amvacuumcleanup safety bug.
- c59278a1aa5e 15.0 landed
- f6162c020c88 14.1 landed
-
Simplify state managed by VACUUM.
- b4af70cb2103 14.0 cited