From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <akorotkov(at)postgresql(dot)org> |
Subject: | Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET,RESET} |
Date: | 2021-10-30 00:45:50 |
Message-ID: | YXyVvhe4R/GjkSri@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-10-30 00:48:59 | Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET, RESET} |
Previous Message | Robert Haas | 2021-10-30 00:34:15 | Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) |