Robert Haas writes:
> On Wed, Dec 20, 2017 at 6:06 PM, Tom Lane wrote:
>> Anyway, I left it as-is, but I'm willing to make the change if
>> people feel the other way is better.
> I feel the other way -- let's not add more pointer indirections if it
> isn't really necessary.
OK --- with any luck
On Wed, Dec 20, 2017 at 6:06 PM, Tom Lane wrote:
> Anyway, I left it as-is, but I'm willing to make the change if
> people feel the other way is better.
I feel the other way -- let's not add more pointer indirections if it
isn't really necessary.
--
Robert Haas
EnterpriseDB: http://www.enterpri
I wrote:
> * Redesign the API for the ParamListInfo paramFetch hook so that the
> ParamExternData array can be entirely virtual. Typical access to
> the info about a PARAM_EXTERN Param now looks like
>
> if (paramInfo->paramFetch != NULL)
> prm = paramInfo->paramFetch(paramInf
I wrote:
> Will send a patch in a bit. I need to write an explanation of what all
> I changed.
OK then. What the attached patch does is:
* Create a new step type EEOP_PARAM_CALLBACK (if anyone has a better
naming idea, I'm receptive) and add the infrastructure needed for
add-on modules to gener
Andres Freund writes:
> On 2017-12-20 12:12:48 -0500, Tom Lane wrote:
>> I'm using several different test cases, but one that shows up the problem
>> is [...]
> Which certainly seems interesting. The outer ExecInterpExpr() indeed
> doesn't do that much, it's the inner call that's the most relevan
Hi,
On 2017-12-20 12:12:48 -0500, Tom Lane wrote:
> Andres Freund writes:
> > What's the workload you're testing? I'm mildly surprised to see
> > ExecEvalParamExtern() show up, rather than just plpgsql_param_fetch() &
> > exec_eval_datum(). Or were you just listing that to specify the
> > callpat
Andres Freund writes:
> On 2017-12-19 13:00:41 -0500, Tom Lane wrote:
>> I'm looking at ways to get plpgsql expression evaluation to go faster,
>> and one thing I'm noticing is the rather large overhead of going through
>> ExecEvalParamExtern and plpgsql_param_fetch to get to the useful work
>> (e
Hi,
Cool to see you looking at that, I think there's quite some optimization
potential around. I've to reread a bunch of plpgsql code, it's not
exactly an area of the code I'm intimately familiar with.
On 2017-12-19 13:00:41 -0500, Tom Lane wrote:
> I'm looking at ways to get plpgsql expression
