Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit6719b23

Browse files
committed
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:* Create a new expression execution step type EEOP_PARAM_CALLBACKand add the infrastructure needed for add-on modules to generate that.As discussed, the best control mechanism for that seems to be to addanother hook function to ParamListInfo, which will be called byExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.For stand-alone expressions, we add a new entry point to allow theParamListInfo to be specified directly, since it can't be retrievedfrom the parent plan node's EState.* Redesign the API for the ParamListInfo paramFetch hook so that theParamExternData array can be entirely virtual. This also lets us get ridof ParamListInfo.paramMask, instead leaving it to the paramFetch hook todecide which param IDs should be accessible or not. plpgsql_param_fetchwas already doing the identical masking check, so having callers do it tooseemed redundant. While I was at it, I added a "speculative" flag toparamFetch that the planner can specify as TRUE to avoid unwanted failures.This solves an ancient problem for plpgsql that it couldn't provide valuesof non-DTYPE_VAR variables to the planner for fear of triggering premature"record not assigned yet" or "field not found" errors during planning.* Rework plpgsql to get rid of the need for "unshared" parameter lists,by dint of turning the single ParamListInfo per estate into a nearlyread-only data structure that doesn't instantiate any per-variable data.Instead, the paramFetch hook controls access to per-variable data and canmake the right decisions on the fly, replacing the cases that we used toneed multiple ParamListInfos for. This might perhaps have been aperformance loss on its own, but by using a paramCompile hook we canbypass plpgsql_param_fetch entirely during normal query execution.(It's now only called when, eg, we copy the ParamListInfo into a cursorportal. copyParamList() or SerializeParamList() effectively instantiatethe virtual parameter array as a simple physical array without aparamFetch hook, which is what we want in those cases.) This allowsreverting most of commit6c82d8d, though I kept the cosmeticcode-consolidation aspects of that (eg the assign_simple_var function).Performance testing shows this to be at worst a break-even change,and it can provide wins ranging up to 20% in test cases involvingaccesses to fields of "record" variables. The fact that values ofsuch variables can now be exposed to the planner might produce winsin some situations, too, but I've not pursued that angle.In passing, remove the "parent" pointer from the arguments toExecInitExprRec and related functions, instead storing that pointer in atransient field in ExprState. The ParamListInfo pointer for a stand-aloneexpression is handled the same way; we'd otherwise have had to addyet another recursively-passed-down argument in expression compilation.Discussion:https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
1 parent8a0596c commit6719b23

File tree

16 files changed

+613
-406
lines changed

16 files changed

+613
-406
lines changed

‎src/backend/commands/prepare.c

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -399,10 +399,11 @@ EvaluateParams(PreparedStatement *pstmt, List *params,
399399
/* we have static list of params, so no hooks needed */
400400
paramLI->paramFetch=NULL;
401401
paramLI->paramFetchArg=NULL;
402+
paramLI->paramCompile=NULL;
403+
paramLI->paramCompileArg=NULL;
402404
paramLI->parserSetup=NULL;
403405
paramLI->parserSetupArg=NULL;
404406
paramLI->numParams=num_params;
405-
paramLI->paramMask=NULL;
406407

407408
i=0;
408409
foreach(l,exprstates)

‎src/backend/executor/execCurrent.c

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -216,11 +216,14 @@ fetch_cursor_param_value(ExprContext *econtext, int paramId)
216216
if (paramInfo&&
217217
paramId>0&&paramId <=paramInfo->numParams)
218218
{
219-
ParamExternData*prm=&paramInfo->params[paramId-1];
219+
ParamExternData*prm;
220+
ParamExternDataprmdata;
220221

221222
/* give hook a chance in case parameter is dynamic */
222-
if (!OidIsValid(prm->ptype)&&paramInfo->paramFetch!=NULL)
223-
paramInfo->paramFetch(paramInfo,paramId);
223+
if (paramInfo->paramFetch!=NULL)
224+
prm=paramInfo->paramFetch(paramInfo,paramId, false,&prmdata);
225+
else
226+
prm=&paramInfo->params[paramId-1];
224227

225228
if (OidIsValid(prm->ptype)&& !prm->isnull)
226229
{

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp