Hackers,
currently built-in &&, @>, <@ array operators have selectivity estimations while same operator in intarray contrib haven't them. Problem is that operators in intarray contrib still use contsel and contjoinsel functions for selectivity estimation even when built-in operators receive their specific selectivity estimations.
Attached patch adds selectivity estimation functions to &&, @>, <@ operators in intarray contrib. In order to have less code duplication they are just wrappers over built-in selectivity estimation functions.
However, I faced a problem of migration scripts. Currently, ALTER OPERATOR can only change owner and schema of operator not operator parameters themselves. Change pg_operator directly is also not an option. At first, it would be kludge. At second, in order to correctly find corresponding operator in pg_operator migration script need to know schema where extension is installed. But it can't refer @extschema@ because extension is relocatable.
My proposal is to let ALTER OPERATOR change restrict and join selectivity functions of the operator. Also it would be useful to be able to change commutator and negator of operator: extension could add commutators and negators in further versions. Any thoughts?
------
With best regards,
Alexander Korotkov.