| 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 |
| Date: | 2019-04-11 13:49:47 |
| Message-ID: | 20190411134947.GA22043@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| 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 |