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