Re: REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: REINDEX CONCURRENTLY 2.0
Date
Msg-id 20190329154803.gfb4rvmflbniheh3@alap3.anarazel.de
Whole thread Raw
In response to Re: REINDEX CONCURRENTLY 2.0  (Robert Treat <rob@xzilla.net>)
Responses Re: REINDEX CONCURRENTLY 2.0
Re: REINDEX CONCURRENTLY 2.0
List pgsql-hackers
Hi,

On 2019-03-29 11:47:10 -0400, Robert Treat wrote:
> On Fri, Mar 29, 2019 at 3:28 AM Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
> >
> > On 2019-03-28 09:07, Sergei Kornilov wrote:
> > > Unfortunately patch does not apply due recent commits. Any chance this can be fixed (and even committed in
pg12)?
> >
> > Committed :)
> >
> 
> Given this has been committed I've probably missed the window, but
> philosophically speaking, is there any reason not to make the
> "concurrently" behavior the default behavior, and require a keyword
> for the more heavy-weight old behavior?

Yes, it increases the total runtime quite considerably. And it adds new
failure modes with partially built invalid indexes hanging around that
need to be dropped manually.


> In most production scenarios
> you probably want to avoid exclusive locking, and in the cases where
> that isn't an issue, 'concurrently' isn't that much slower that most
> users would object to it.

It does at *least* twice as much IO.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: REINDEX CONCURRENTLY 2.0
Next
From: Joe Conway
Date:
Subject: Re: PostgreSQL pollutes the file system