Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET,RESET} - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET,RESET}
Date
Msg-id YXyVvhe4R/GjkSri@paquier.xyz
Whole thread Raw
In response to Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET,RESET}  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET,RESET}  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Fri, Oct 29, 2021 at 11:15:08PM +0300, Alexander Korotkov wrote:
> All these cases require index rebuild to change the opclass option.  I
> can imagine there could be options, which don't require index rebuild
> to change.  For instance, a split algorithm for R-tree-like GiST index
> could be changed on the fly.  But not much point to change it on the
> existing index, though.

This point alone is enough to say that what the patch does is not
enough, then, thanks.  An index rebuild would require an exclusive
lock, but AT_SetOptions uses a share update exclusive lock.  We could
keep the same lock level by trigerring a concurrent reindex while
forbidding running this command flavor on indexes within a transaction
block, though.  I guess that this still makes the life or users a bit
easier to avoid mistakes with complicated index expressions or
predicates, but that also feels like adding code for little gain.

Another thing that could be done is to mark the index as invalid once
its set of opclass parameters is updated.  That would be simpler,
while allowing users to fire a concurrent or non-concurrent rebuild at
will after an ALTER INDEX.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Next
From: Michael Paquier
Date:
Subject: Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET, RESET}