From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
Cc: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>, 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 00:22:38 |
Message-ID: | Yk+ATh9TbWHjtXfp@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(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.
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-04-08 00:31:22 | Re: Collecting statistics about contents of JSONB columns |
Previous Message | Justin Pryzby | 2022-04-08 00:07:56 | Re: logical decoding and replication of sequences |