Re: REINDEX blocks virtually any queries but some prepared queries.
От | Frédéric Yhuel |
---|---|
Тема | Re: REINDEX blocks virtually any queries but some prepared queries. |
Дата | |
Msg-id | dcdfea80-9f7a-66f7-95d0-b38b976c2c4d@dalibo.com обсуждение исходный текст |
Ответ на | Re: REINDEX blocks virtually any queries but some prepared queries. (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: REINDEX blocks virtually any queries but some prepared queries.
|
Список | pgsql-hackers |
On 4/8/22 02:22, Michael Paquier wrote: > 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. > Thank you Michael. >>> 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. Indeed! Best regards, Frédéric
В списке pgsql-hackers по дате отправления: