Re: REINDEX CONCURRENTLY 2.0

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: REINDEX CONCURRENTLY 2.0
Дата
Msg-id 20190329154803.gfb4rvmflbniheh3@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: REINDEX CONCURRENTLY 2.0  (Robert Treat <rob@xzilla.net>)
Ответы Re: REINDEX CONCURRENTLY 2.0
Re: REINDEX CONCURRENTLY 2.0
Список 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 по дате отправления:

Предыдущее
От: Robert Treat
Дата:
Сообщение: Re: REINDEX CONCURRENTLY 2.0
Следующее
От: Joe Conway
Дата:
Сообщение: Re: PostgreSQL pollutes the file system