Re: Parallel heap vacuum

On Wed, Sep 17, 2025 at 7:25 AM Tomas Vondra <tomas(at)vondra(dot)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