Re: Parallel heap vacuum - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Parallel heap vacuum
Date
Msg-id CA+Tgmob_WzU84cdRjVUFk7D_TaDZ6p-31t23=H5Dyy=jPohETQ@mail.gmail.com
Whole thread Raw
In response to Re: Parallel heap vacuum  (Tomas Vondra <tomas@vondra.me>)
Responses Re: Parallel heap vacuum
Re: Parallel heap vacuum
List pgsql-hackers
On Wed, Sep 17, 2025 at 7:25 AM Tomas Vondra <tomas@vondra.me> wrote:
> I took a quick look at the patch this week. I don't have a very strong
> opinion on the changes to table AM API, and I somewhat agree with this
> impression. It's not clear to me why we should be adding callbacks that
> are AM-specific (and only ever called from that particular AM) to the
> common AM interface.

We clearly should not do that.

> I keep thinking about how we handle parallelism in index builds. The
> index AM API did not get a bunch of new callbacks, it's all handled
> within the existing ambuild() callback. Shouldn't we be doing something
> like that for relation_vacuum()?

I have a feeling that we might have made the wrong decision there.
That approach will probably require a good deal of code to be
duplicated for each AM. I'm not sure what the final solution should
look like here, but we want the common parts like worker setup to use
common code, while allowing each AM to insert its own logic in the
places where that is needed. The challenge in my view is to figure out
how best to arrange things so as to make that possible.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Remove PointerIsValid()
Next
From: Sami Imseih
Date:
Subject: Re: GetNamedLWLockTranche crashes on Windows in normal backend