From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Selectivity estimation for intarray |
Date: | 2015-04-29 15:30:45 |
Message-ID: | 35246.1430321445@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-04-29 15:36:04 | Re: Selectivity estimation for intarray |
Previous Message | Stephen Frost | 2015-04-29 14:47:22 | Re: Additional role attributes && superuser review |