diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2015-03-11 12:40:43 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2015-03-11 12:40:43 -0400 |
commit | 21dcda2713656a7483e3280ac9d2ada20a87a9a9 (patch) | |
tree | 322f3576e63d26db99f377c3a2d748b5a3280fd2 /src/backend/parser/parse_expr.c | |
parent | e96b7c6b9fc4d148a22588894245416b63743368 (diff) | |
download | postgresql-21dcda2713656a7483e3280ac9d2ada20a87a9a9.tar.gz postgresql-21dcda2713656a7483e3280ac9d2ada20a87a9a9.zip |
Allocate ParamListInfo once per plpgsql function, not once per expression.
setup_param_list() was allocating a fresh ParamListInfo for each query or
expression evaluation requested by a plpgsql function. There was probably
once good reason to do it like that, but for a long time we've had a
convention that there's a one-to-one mapping between the function's
PLpgSQL_datum array and the ParamListInfo slots, which means that a single
ParamListInfo can serve all the function's evaluation requests: the data
that would need to be passed is the same anyway.
In this patch, we retain the pattern of zeroing out the ParamListInfo
contents during each setup_param_list() call, because some of the slots may
be stale and we don't know exactly which ones. So this patch only saves a
palloc/pfree per evaluation cycle and nothing more; still, that seems to be
good for a couple percent overall speedup on simple-arithmetic type
statements. In future, though, we might be able to improve matters still
more by managing the param array contents more carefully.
Also, unify the former use of estate->cur_expr with that of
paramLI->parserSetupArg; they both were used to point to the active
expression, so we can combine the variables into just one.
Diffstat (limited to 'src/backend/parser/parse_expr.c')
0 files changed, 0 insertions, 0 deletions