Re: clearing opfuncid vs. parallel query

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: clearing opfuncid vs. parallel query
Дата
Msg-id CA+TgmoYJxx3pm_WttvnC=t3TBy4JSM8bCJ_WMZ-h5ZsEkWziaQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: clearing opfuncid vs. parallel query  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: clearing opfuncid vs. parallel query  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: DBT-3 with SF=20 got failed
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: DBT-3 with SF=20 got failed