From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Allocate ParamListInfo once per plpgsql function, not once per e |
Date: | 2015-03-11 16:40:51 |
Message-ID: | E1YVjgh-0005E2-IS@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/21dcda2713656a7483e3280ac9d2ada20a87a9a9
Modified Files
--------------
src/pl/plpgsql/src/pl_exec.c | 91 ++++++++++++++++++++++--------------------
src/pl/plpgsql/src/plpgsql.h | 4 +-
2 files changed, 50 insertions(+), 45 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-03-11 17:22:58 | pgsql: Make operator precedence follow the SQL standard more closely. |
Previous Message | Robert Haas | 2015-03-11 16:13:29 | pgsql: sepgsql: Improve error message when unsupported object type is l |