From: | Robert Treat <rob(at)xzilla(dot)net> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | 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:47:10 |
Message-ID: | CABV9wwMQS6CoS5OrTfZFZJX53jOJNHP35y9MeuBeKF-++LbpYg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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? 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. I would perhaps give a nod to historical
syntax concerns, but this would more closely align with the behavior
in vacuum vs vacuum full, and we've done behavior modifying changes
such as the recent WITH ... MATERIALIZED change. Thoughts?
Robert Treat
https://xzilla.net
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-03-29 15:48:03 | Re: REINDEX CONCURRENTLY 2.0 |
Previous Message | Daniel Gustafsson | 2019-03-29 15:44:05 | Re: PostgreSQL pollutes the file system |