Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET,RESET}

Hi, Michael!

On Fri, Oct 29, 2021 at 12:10 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Fri, Oct 29, 2021 at 02:09:34PM +0900, Michael Paquier wrote:
> > The attached does the work, with tests and documentation added to all
> > the places I could think about while reviewing the existing opclass
> > code for indexes. There is no need to worry about pg_dump, as opclass
> > parameters are loaded with CREATE INDEX.
>
> By the way, while looking at this area of the code (particularly
> tsvector and gist), I was under the impression that it is safe to
> assume that we don't particularly need to rebuild the index when
> changing its attoptions this way, but I have also the feeling to be
> rather naive here.
>
> Alexander, you have much more experience in this area than I do, what
> are your thoughts on the matter?

Good question, thanks.

I keep the following use cases in my mind for this feature:
1) One could set up paths to index within the json document (using
jsonpath or another language);
2) The way to index particular paths in json document: for instance,
we can index string "as is" or just hash value;
3) For signatures, we may specify the number of bits to set in
addition to the signature length.

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.

We may introduce the additional property of opclass option
"mutability", which specifies whether it's possible to change for the
existing index. So, I don't think this is viable for now. I suggest
postponing it. Leave the options immutable, until we get some solid
use-cases of mutable options.

------
Regards,
Alexander Korotkov