Re: REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: REINDEX CONCURRENTLY 2.0
Date
Msg-id 20190411134947.GA22043@alvherre.pgsql
Whole thread Raw
In response to Re: REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael@paquier.xyz>)
Responses Re: REINDEX CONCURRENTLY 2.0
List pgsql-hackers
On 2019-Apr-11, Michael Paquier wrote:

> > I was going to just remove the caveat, but then I discovered that
> > REINDEX CONCURRENTLY doesn't work on INVALID indexes (why?).
> 
> This is a wanted choice.  The index built in parallel of the existing
> one during a concurrent reindex is marked invalid during most of the
> operation.  Hence, if the reindex is interrupted or fails, you finish
> with potentially twice the number of original indexes, half being
> invalid and the other half being the ones in use.  If the user decides
> to rinse and repeat the concurrent reindex, and if we were to also
> select invalid indexes for the operation, then you would finish by
> potentially doing twice the amount of work when working on a relation,
> half of it for nothing.

Hmm, I suppose that makes sense for REINDEX TABLE or anything that
reindexes more than one index, but if you do REINDEX INDEX surely it
is reasonable to allow the case?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: block-level incremental backup
Next
From: Konstantin Knizhnik
Date:
Subject: Re: Zedstore - compressed in-core columnar storage