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
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
(exec_eval_datum). We've ameliorated that for DTYPE_VAR variables
by keeping a pre-s
