Re: REINDEX CONCURRENTLY 2.0

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
Cc: 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:27:04
Message-ID: 20190411132704.GC30766@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 11, 2019 at 11:21:29AM +0100, Dagfinn Ilmari Mannsåker wrote:
> I noticed that the docs for how to recover from a failed CREATE INDEX
> CONCURRENTLY say that «REINDEX does not support concurrent builds»,
> which is no longer true.

Good catch. I'll apply that in a couple of hours.

> 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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-04-11 13:27:19 Re: finding changed blocks using WAL scanning
Previous Message Andreas Karlsson 2019-04-11 13:18:41 Re: Zedstore - compressed in-core columnar storage