Re: Selectivity estimation for intarray

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> > 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?
>
> I'm pretty dubious about this, because we lack any mechanism for undoing
> parser/planner decisions based on operator properties. And there's quite
> a lot of stuff that is based on the assumption that operator properties
> will never change.
>
> An example of the pitfalls here is that we can never allow ALTER OPERATOR
> RENAME, because for example if you rename '<' to '~<~' that will change
> its precedence, and we have no way to fix the parse trees embedded in
> stored views to reflect that.
>
> For the specific cases you mention, perhaps it would be all right if we
> taught plancache.c to blow away *all* cached plans upon seeing any change
> in pg_operator; but that seems like a brute-force solution.

Agreed that it is- but is that really a problem...? I've not run into
many (any?) systems where pg_operator is getting changed often... The
worst part would be adding new operators/extensions, but perhaps we
could exclude that specific case from triggering the cache invalidation?

Thanks!

Stephen