Re: REINDEX blocks virtually any queries but some prepared queries.

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: REINDEX blocks virtually any queries but some prepared queries.
Дата
Msg-id Yk+ATh9TbWHjtXfp@paquier.xyz
обсуждение исходный текст
Ответ на Re: REINDEX blocks virtually any queries but some prepared queries.  (Guillaume Lelarge <guillaume@lelarge.info>)
Ответы Re: REINDEX blocks virtually any queries but some prepared queries.
Список pgsql-hackers
On Thu, Apr 07, 2022 at 05:29:36PM +0200, Guillaume Lelarge a écrit :
> Le jeu. 7 avr. 2022 à 15:44, Frédéric Yhuel <frederic.yhuel@dalibo.com> a écrit :
>> On 4/7/22 14:40, Justin Pryzby wrote:
>> Thank you Justin! I applied your fixes in the v2 patch (attached).
>
> v2 patch sounds good.

The location of the new sentence and its wording seem fine to me.  So
no objections from me to add what's suggested, as suggested.  I'll
wait for a couple of days first.

>> Indeed ;) That being said, REINDEX CONCURRENTLY could give you an
>> invalid index, so sometimes you may be tempted to go for a simpler
>> REINDEX, especially if you believe that the SELECTs won't be blocked.
>
> Agreed.

There are many factors to take into account, one is more expensive
than the other in terms of resources and has downsides, downsides
compensated by the reduction in the lock requirements.  There are
cases where REINDEX is a must-have, as CONCURRENTLY does not support
catalog indexes, and these tend to be easily noticed when corruption
spreads around.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: logical decoding and replication of sequences
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Collecting statistics about contents of JSONB columns