| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Treat <rob(at)xzilla(dot)net> |
| 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-03-29 15:48:03 |
| Message-ID: | 20190329154803.gfb4rvmflbniheh3@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(dot)eisentraut(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2019-03-29 15:48:47 | Re: PostgreSQL pollutes the file system |
| Previous Message | Robert Treat | 2019-03-29 15:47:10 | Re: REINDEX CONCURRENTLY 2.0 |