Re: Inlining functions with "expensive" parameters
От | Andres Freund |
---|---|
Тема | Re: Inlining functions with "expensive" parameters |
Дата | |
Msg-id | 8C818B71-B87B-471E-B2EA-30CF509E8B18@anarazel.de обсуждение исходный текст |
Ответ на | Re: Inlining functions with "expensive" parameters (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Inlining functions with "expensive" parameters
Re: Inlining functions with "expensive" parameters Re: Inlining functions with "expensive" parameters |
Список | pgsql-hackers |
On November 16, 2017 11:44:52 AM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote: >Andres Freund <andres@anarazel.de> writes: >> Well, it's not a question of cost of the function now? Imagine >> SELECT inlineable(something()); >> if you have 10 references for the parameter inside inlineable(). Then >> currently something() would be evaluated 10 times. Which'd quite >> possibly be bad. > >Right. I kind of thought we only worried about that if the parameter >was referenced more than once, but I might be wrong. You're not. >> But what I *am* wondering about, is why we're not handling the >> parameters in a different way. Instead of replacing the all parameter >> references with the parameter, it shouldn't be too hard to instead >> replace them with a new PARAM_EXEC like Param. > >Yeah, there's no mechanism like that now, but there could be. 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 wonder >if we could connect that to the work that was being done for caching >nonvolatile subexpressions --- it feels like much the same problem. Yes, that sounds like it could be related. Looks like the expression representation and the execution side of things shouldbe the same. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
В списке pgsql-hackers по дате отправления: