On Thu, Dec 19, 2019 at 12:05 PM Robert Haas <robertmh...@gmail.com> wrote: > My impression is that this is more of an implementation restriction > than a design goal. I don't really remember the details, but it seems > to me that there were locking and/or cache invalidation problems with > making ALTER OPERATOR CLASS do more substantive things -- and that it > was because of those problems, not a lack of desire, that we didn't > support it.
I agree with you. My point was only that this is something that the operator class author is really expected to get right the first time around -- just like the behavior of B-Tree support function 1. We're really only concerned about the upgrade path for external types that could see a benefit from the optimization planned for nbtree (and possibly other such optimization). Providing a non-disruptive way to get that benefit after a pg_upgrade only seems like a nice-to-have to me, because it's not as if anything will stop working as well as it once did. Also, there aren't that many external types that will be made more useful by being able to use optimizations like deduplication; in practice almost all B-Tree indexes only use a small handful of operator classes that are shipped in core Postgres. Once you're using common types like text and integer, a pg_upgrade'd database is only a REINDEX away from being able to use deduplication (though I am not even sure if even that will be necessary in the final patch; I hope to be able to avoid even that inconvenience with indexes using core operator classes). If the underlying behavior of an operator class actually changes, then that's a disaster for all the usual reasons. It doesn't make that much sense to reverse an earlier decision to make an operator class BITWISE. Better to drop everything, and recreate everything, since your indexes should be considered corrupt anyway. (Also, I don't think that it's that hard to get it right, so this will probably never happen.) -- Peter Geoghegan
