|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: REINDEX CONCURRENTLY 2.0|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|Next Message||Konstantin Knizhnik||2019-04-11 13:52:33||Re: Zedstore - compressed in-core columnar storage|
|Previous Message||Robert Haas||2019-04-11 13:45:52||Re: block-level incremental backup|