Re: pgsql: reindexdb: Add the index-level REINDEX with multiple jobs - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: pgsql: reindexdb: Add the index-level REINDEX with multiple jobs
Date
Msg-id CAPpHfds_hJh1vYMAsATDNNDFXygyosD0n7M=HXwCiJTphvWCCg@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: reindexdb: Add the index-level REINDEX with multiple jobs  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: pgsql: reindexdb: Add the index-level REINDEX with multiple jobs
List pgsql-hackers
On Sat, Mar 8, 2025 at 12:49 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Fri, Mar 7, 2025 at 8:20 PM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >
> > On 2024-Mar-25, Alexander Korotkov wrote:
> >
> > > reindexdb: Add the index-level REINDEX with multiple jobs
> > >
> > > Straight-forward index-level REINDEX is not supported with multiple jobs as
> > > we cannot control the concurrent processing of multiple indexes depending on
> > > the same relation.  Instead, we dedicate the whole table to certain reindex
> > > job.  Thus, if indexes in the lists belong to different tables, that gives us
> > > a fair level of parallelism.
> >
> > I tested this, because of a refactoring suggestion [1] and I find that
> > it's rather completely broken.
>
> The code was written with assumption that running
> run_reindex_command() with async == true can schedule a number of
> queries for a connection.  But actually that's not true and everything
> is broken.

The draft patch for revert is attached.  Could you, please, check.

------
Regards,
Alexander Korotkov
Supabase

Attachment

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Printing window function OVER clauses in EXPLAIN
Next
From: Masahiko Sawada
Date:
Subject: Re: Add an option to skip loading missing publication to avoid logical replication failure