Re: Parallel heap vacuum - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel heap vacuum
Date
Msg-id CAA4eK1Jv7hrZNN=MGX34a5HqDRK3UV533aqPoaOHG3htGOi1DQ@mail.gmail.com
Whole thread Raw
In response to Re: Parallel heap vacuum  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Parallel heap vacuum
List pgsql-hackers
On Wed, Mar 12, 2025 at 11:24 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Wed, Mar 12, 2025 at 3:17 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Tue, Mar 11, 2025 at 5:51 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
>
> Some thoughts/questions on the idea
>
> I notice that we are always considering block-level parallelism for
> heaps and object-level parallelism for indexes. I'm wondering, when
> multiple tables are being vacuumed together—either because the user
> has provided a list of tables or has specified a  partitioned table
> with multiple children—does it still make sense to default to
> block-level parallelism? Or could we consider table-level parallelism
> in such cases? For example, if there are 4 tables and 6 workers, with
> 2 tables being small and the other 2 being large, perhaps we could
> allocate 4 workers to vacuum all 4 tables in parallel. For the larger
> tables, we could apply block-level parallelism, using more workers for
> internal parallelism. On the other hand, if all tables are small, we
> could just apply table-level parallelism without needing block-level
> parallelism at all. This approach could offer more flexibility, isn't
> it?
>

I have not thought from this angle, but it seems we can build this
even on top of block-level vacuum for large tables.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Question about duplicate JSONTYPE_JSON check
Next
From: Dilip Kumar
Date:
Subject: Re: Parallel heap vacuum