On 9/17/25 18:32, Robert Haas wrote:
> On Wed, Sep 17, 2025 at 12:23 PM Tomas Vondra <tomas@vondra.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
