| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Inlining functions with "expensive" parameters |
| Date: | 2017-11-21 14:59:00 |
| Message-ID: | CA+TgmoZd+X-A0ZgGd9zzzC_tYcqPsY7uS=DER3ox0f+hFZpq3w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Nov 16, 2017 at 2:51 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Right, but it doesn't sound that hard to introduce. Basically there'd need to be a WithParamValue node, that first evaluates parameters and then executes the child expression. I'm thinking of doing this hierarchically so there's less issues with 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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-11-21 15:04:19 | Re: Inlining functions with "expensive" parameters |
| Previous Message | Ildus Kurbangaliev | 2017-11-21 14:47:17 | Re: [HACKERS] Custom compression methods |