MIME-Version: 1.0
References: <202503071820.j25zn3lo4hvn@alvherre.pgsql>
 <202503080956.vjxmabdkatan@alvherre.pgsql>
In-Reply-To: <202503080956.vjxmabdkatan@alvherre.pgsql>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Sat, 8 Mar 2025 12:42:41 +0200
Message-ID: 
 <CAPpHfdv9QjNPNt+c+1qrtO2bHtSUE4zybWkGfUQa4kKSV5QOmA@mail.gmail.com>
Subject: Re: pgsql: reindexdb: Add the index-level REINDEX with multiple jobs
To: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@alvh.no-ip.org>
Cc: Alexander Korotkov <akorotkov@postgresql.org>,
 pgsql-hackers@lists.postgresql.org,
	Maxim Orlov <orlovmg@gmail.com>,
 Svetlana Derevyanko <s.derevyanko@postgrespro.ru>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPpHfdv9QjNPNt%2Bc%2B1qrtO2bHtSUE4zybWkGfUQa4kKSV5QOmA%40mail.gmail.com>
Precedence: bulk

On Sat, Mar 8, 2025 at 11:57=E2=80=AFAM =C3=81lvaro Herrera <alvherre@alvh.=
no-ip.org> wrote:
>
> On 2025-Mar-07, =C3=81lvaro Herrera wrote:
>
> > I tested this, because of a refactoring suggestion [1] and I find that
> > it's rather completely broken.
>
> I think we need significantly more complex scheduling code if we want
> this to actually work, possibly even having to hack the ParallelSlot
> API some, so that we can inspect which tables have a running reindex and
> know not to schedule the next one on it.  What we're doing now makes no
> sense.
>
> We should strike this out from the list of features of 17 and revert
> this commit.
>
> If we want this feature in 19, we need another go through the drawing
> board.  (There's clearly not enough time to do it for 18.)

Yes, I also think we need to revert this from 17.  One thing to care
about: it might be already used in some user scripts.  Should we
replace pg_fatal() with some notice and then run in a single job?  So,
user scripts wouldn't error out.

------
Regards,
Alexander Korotkov
Supabase