Re: clearing opfuncid vs. parallel query - Mailing list pgsql-hackers

From Robert Haas
Subject Re: clearing opfuncid vs. parallel query
Date
Msg-id CA+TgmoYJxx3pm_WttvnC=t3TBy4JSM8bCJ_WMZ-h5ZsEkWziaQ@mail.gmail.com
Whole thread Raw
In response to Re: clearing opfuncid vs. parallel query  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: clearing opfuncid vs. parallel query  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Sep 24, 2015 at 12:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Also, it's not like this change couldn't be UN-done at a future point.
>> I mean, Tom didn't like the flag I added aesthetically, but if we
>> needed it, we could have it.  Or we could engineer something else.
>
> 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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: DBT-3 with SF=20 got failed
Next
From: Tomas Vondra
Date:
Subject: Re: DBT-3 with SF=20 got failed