Re: Parallel heap vacuum

On 9/17/25 18:32, Robert Haas wrote:
> On Wed, Sep 17, 2025 at 12:23 PM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>> Look at the BRIN code, for example. Most of the parallel stuff happens
>> in _brin_begin_parallel. Maybe more of it could be generalized a bit
>> more (some of the shmem setup?). But most of it is tied to the
>> AM-specific state / how parallel builds work for that particular AM.
>
> Well, the code for PARALLEL_KEY_WAL_USAGE, PARALLEL_KEY_BUFFER_USAGE,
> and PARALLEL_KEY_QUERY_TEXT is duplicated, for instance. That's not a
> ton of code, perhaps, but it may evolve over time, and having to keep
> copies for a bunch of different AMs in sync is not ideal.
>

True. And I agree it's not great it might break if we need to setup the
wal/buffer usage tracking a bit differently (and forget to update all
the places, or even can't do that in custom AMs).

I suppose we could wrap that in a helper, and call that? That's what I
meant by "maybe we could generalize the shmem setup".

The alternative would be to have a single AM-agnostic place doing
parallel builds with any index AM, and calls "AM callbacks" instead.
AFAICS that's pretty much how Melanie imagines the parallel vacuum to
work (at least that's how I understand it).

I'm not sure which way is better. I'm terrible in designing APIs.

For the parallel heap vacuum, the patches seem to be a bit 50:50. The
per-AM callbacks are there, but each AM still has to do the custom code
anyway.

--
Tomas Vondra