Re: Inlining functions with "expensive" parameters

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Inlining functions with "expensive" parameters
Дата
Msg-id 20171121164247.z6d5pwbdk7f5cr3z@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Inlining functions with "expensive" parameters  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2017-11-21 09:59:00 -0500, Robert Haas wrote:
> On Thu, Nov 16, 2017 at 2:51 PM, Andres Freund <andres@anarazel.de> wrote:
> > Right, but it doesn't sound that hard to introduce. Basically there'd need to be a WithParamValue node,  that first
evaluatesparameters and then executes the child expression. I'm thinking of doing this hierarchically so there's less
issueswith the setting of the param value being moved away from the child expression using it.
 
> 
> I don't quite follow the need for this.  I mean, if we just stick a
> Param reference in there and create a corresponding InitPlan, the
> Param will be evaluated on demand, right?  Is the point of the new
> node to make sure that the Param gets re-evaluated when needed?

It'll work in some of those cases. But you e.g. can't use an InitPlan to
reference to a table's columns without some major contortions, no?
Inlining stuff like SELECT * FROM foo WHERE sql_func(foo.blarg, anotherfunc());
is pretty important for some usecases. The re-evaluation concern's also
there, this should also work with e.g. volatile parameters like
nextval(), without establishing a second mechanism to deal with them.

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: feature request: consume asynchronous notification via a function
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Inlining functions with "expensive" parameters