Re: clearing opfuncid vs. parallel query

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Sep 24, 2015 at 12:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> For the record: that's true for the patch you just committed. But once
>> I remove the hopefully-now-dead planner support for recomputing opfuncid,
>> it would get a lot more painful to reverse the decision.

> True. I think it's pretty wacky that we store the opfuncid in the
> tree at all. If somebody were to propose adding a dependent value of
> that sort to a node type that didn't already have it, I suspect either
> you or I would do our best to shoot that down. The only possible
> argument for having that in there at all is that the performance gains
> from so doing are so large that we have no choice but to sacrifice a
> principle to expediency.

Hm. It might be interesting to try removing those node fields altogether
and see what it costs us. Setting the field at parse time is zero-cost,
at least in the primary code path through make_op(), because we have our
hands on the pg_operator row at that time anyway. (I have a vague
recollection that that was once not true, but it certainly is true now
and has been for a long time.) Not having it would cost us one syscache
lookup per operator at execution start, and maybe more than that if there
are additional places that would need the function OID, which there
probably are --- volatility checks in the planner come to mind. But
I'm not sure how significant that would be. There are certainly plenty
of syscache lookups being done at plan startup anyway.

But this is mostly moot unless someone is actively planning to try to
implement ALTER OPERATOR SET FUNCTION.

regards, tom lane