From: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: REINDEX blocks virtually any queries but some prepared queries. |
Date: | 2022-04-08 14:23:48 |
Message-ID: | dcdfea80-9f7a-66f7-95d0-b38b976c2c4d@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)yhuel(at)dalibo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amul Sul | 2022-04-08 14:27:03 | Re: [Patch] ALTER SYSTEM READ ONLY |
Previous Message | Robert Haas | 2022-04-08 14:20:27 | Re: remove more archiving overhead |