Re: Parallel heap vacuum
От | Tomas Vondra |
---|---|
Тема | Re: Parallel heap vacuum |
Дата | |
Msg-id | bae53977-f2db-436f-aed7-145eeced21a6@vondra.me обсуждение исходный текст |
Ответ на | Re: Parallel heap vacuum (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Parallel heap vacuum
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: