1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* execUtils.c
|
2000-07-12 04:37:39 +02:00
|
|
|
* miscellaneous executor utility routines
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2017-01-03 19:48:53 +01:00
|
|
|
* Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/executor/execUtils.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
/*
|
|
|
|
* INTERFACE ROUTINES
|
2002-12-15 17:17:59 +01:00
|
|
|
* CreateExecutorState Create/delete executor working state
|
|
|
|
* FreeExecutorState
|
|
|
|
* CreateExprContext
|
2006-08-04 23:33:36 +02:00
|
|
|
* CreateStandaloneExprContext
|
2002-12-15 17:17:59 +01:00
|
|
|
* FreeExprContext
|
2003-12-18 21:21:37 +01:00
|
|
|
* ReScanExprContext
|
2002-12-15 17:17:59 +01:00
|
|
|
*
|
2000-07-12 04:37:39 +02:00
|
|
|
* ExecAssignExprContext Common code for plan node init routines.
|
2002-12-15 17:17:59 +01:00
|
|
|
* ExecAssignResultType
|
|
|
|
* etc
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2005-12-02 21:03:42 +01:00
|
|
|
* ExecOpenScanRelation Common code for scan node init routines.
|
|
|
|
* ExecCloseScanRelation
|
|
|
|
*
|
2017-04-18 19:20:59 +02:00
|
|
|
* executor_errposition Report syntactic position of an error.
|
|
|
|
*
|
2002-05-12 22:10:05 +02:00
|
|
|
* RegisterExprContextCallback Register function shutdown callback
|
|
|
|
* UnregisterExprContextCallback Deregister function shutdown callback
|
|
|
|
*
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
* GetAttributeByName Runtime extraction of columns from tuples.
|
|
|
|
* GetAttributeByNum
|
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* NOTES
|
|
|
|
* This file has traditionally been the place to stick misc.
|
|
|
|
* executor support stuff that doesn't really go anyplace else.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
|
1996-10-31 11:12:26 +01:00
|
|
|
#include "postgres.h"
|
|
|
|
|
2009-12-07 06:22:23 +01:00
|
|
|
#include "access/relscan.h"
|
|
|
|
#include "access/transam.h"
|
2015-04-24 08:33:23 +02:00
|
|
|
#include "executor/executor.h"
|
2017-04-18 19:20:59 +02:00
|
|
|
#include "mb/pg_wchar.h"
|
2009-04-03 00:39:30 +02:00
|
|
|
#include "nodes/nodeFuncs.h"
|
2005-12-02 21:03:42 +01:00
|
|
|
#include "parser/parsetree.h"
|
2017-03-21 14:48:04 +01:00
|
|
|
#include "storage/lmgr.h"
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
#include "utils/builtins.h"
|
2000-07-12 04:37:39 +02:00
|
|
|
#include "utils/memutils.h"
|
2015-04-24 08:33:23 +02:00
|
|
|
#include "utils/rel.h"
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
#include "utils/typcache.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-08-19 23:40:56 +02:00
|
|
|
|
2017-11-25 16:49:17 +01:00
|
|
|
static bool tlist_matches_tupdesc(PlanState *ps, List *tlist, Index varno, TupleDesc tupdesc);
|
2009-07-18 21:15:42 +02:00
|
|
|
static void ShutdownExprContext(ExprContext *econtext, bool isCommit);
|
2002-05-12 22:10:05 +02:00
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* ----------------------------------------------------------------
|
2002-12-15 17:17:59 +01:00
|
|
|
* Executor state and memory management functions
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* ----------------
|
2002-12-15 17:17:59 +01:00
|
|
|
* CreateExecutorState
|
2000-07-12 04:37:39 +02:00
|
|
|
*
|
2002-12-15 17:17:59 +01:00
|
|
|
* Create and initialize an EState node, which is the root of
|
|
|
|
* working storage for an entire Executor invocation.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2002-12-15 17:17:59 +01:00
|
|
|
* Principally, this creates the per-query memory context that will be
|
|
|
|
* used to hold all working data that lives till the end of the query.
|
|
|
|
* Note that the per-query context will become a child of the caller's
|
|
|
|
* CurrentMemoryContext.
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
2002-12-15 17:17:59 +01:00
|
|
|
EState *
|
|
|
|
CreateExecutorState(void)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2007-02-27 02:11:26 +01:00
|
|
|
EState *estate;
|
2002-12-15 17:17:59 +01:00
|
|
|
MemoryContext qcontext;
|
2007-02-27 02:11:26 +01:00
|
|
|
MemoryContext oldcontext;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
/*
|
|
|
|
* Create the per-query context for this Executor run.
|
|
|
|
*/
|
|
|
|
qcontext = AllocSetContextCreate(CurrentMemoryContext,
|
|
|
|
"ExecutorState",
|
Add macros to make AllocSetContextCreate() calls simpler and safer.
I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls
had typos in the context-sizing parameters. While none of these led to
especially significant problems, they did create minor inefficiencies,
and it's now clear that expecting people to copy-and-paste those calls
accurately is not a great idea. Let's reduce the risk of future errors
by introducing single macros that encapsulate the common use-cases.
Three such macros are enough to cover all but two special-purpose contexts;
those two calls can be left as-is, I think.
While this patch doesn't in itself improve matters for third-party
extensions, it doesn't break anything for them either, and they can
gradually adopt the simplified notation over time.
In passing, change TopMemoryContext to use the default allocation
parameters. Formerly it could only be extended 8K at a time. That was
probably reasonable when this code was written; but nowadays we create
many more contexts than we did then, so that it's not unusual to have a
couple hundred K in TopMemoryContext, even without considering various
dubious code that sticks other things there. There seems no good reason
not to let it use growing blocks like most other contexts.
Back-patch to 9.6, mostly because that's still close enough to HEAD that
it's easy to do so, and keeping the branches in sync can be expected to
avoid some future back-patching pain. The bugs fixed by these changes
don't seem to be significant enough to justify fixing them further back.
Discussion: <21072.1472321324@sss.pgh.pa.us>
2016-08-27 23:50:38 +02:00
|
|
|
ALLOCSET_DEFAULT_SIZES);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2000-07-12 04:37:39 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Make the EState node within the per-query context. This way, we don't
|
|
|
|
* need a separate pfree() operation for it at shutdown.
|
2000-07-12 04:37:39 +02:00
|
|
|
*/
|
2002-12-15 17:17:59 +01:00
|
|
|
oldcontext = MemoryContextSwitchTo(qcontext);
|
|
|
|
|
|
|
|
estate = makeNode(EState);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize all fields of the Executor State structure
|
|
|
|
*/
|
|
|
|
estate->es_direction = ForwardScanDirection;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
estate->es_snapshot = InvalidSnapshot; /* caller must initialize this */
|
2004-09-11 20:28:34 +02:00
|
|
|
estate->es_crosscheck_snapshot = InvalidSnapshot; /* no crosscheck */
|
2002-12-15 17:17:59 +01:00
|
|
|
estate->es_range_table = NIL;
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
estate->es_plannedstmt = NULL;
|
2002-12-15 17:17:59 +01:00
|
|
|
|
2009-10-12 20:10:51 +02:00
|
|
|
estate->es_junkFilter = NULL;
|
|
|
|
|
2007-11-30 22:22:54 +01:00
|
|
|
estate->es_output_cid = (CommandId) 0;
|
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
estate->es_result_relations = NULL;
|
|
|
|
estate->es_num_result_relations = 0;
|
|
|
|
estate->es_result_relation_info = NULL;
|
|
|
|
|
2017-08-18 19:01:05 +02:00
|
|
|
estate->es_root_result_relations = NULL;
|
|
|
|
estate->es_num_root_result_relations = 0;
|
|
|
|
|
|
|
|
estate->es_leaf_result_relations = NIL;
|
|
|
|
|
2007-08-15 23:39:50 +02:00
|
|
|
estate->es_trig_target_relations = NIL;
|
2005-11-14 18:42:55 +01:00
|
|
|
estate->es_trig_tuple_slot = NULL;
|
2009-11-20 21:38:12 +01:00
|
|
|
estate->es_trig_oldtup_slot = NULL;
|
2011-08-22 00:15:55 +02:00
|
|
|
estate->es_trig_newtup_slot = NULL;
|
2005-11-14 18:42:55 +01:00
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
estate->es_param_list_info = NULL;
|
|
|
|
estate->es_param_exec_vals = NULL;
|
|
|
|
|
2017-04-01 06:17:18 +02:00
|
|
|
estate->es_queryEnv = NULL;
|
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
estate->es_query_cxt = qcontext;
|
|
|
|
|
2009-09-27 22:09:58 +02:00
|
|
|
estate->es_tupleTable = NIL;
|
2000-07-12 04:37:39 +02:00
|
|
|
|
2009-10-12 20:10:51 +02:00
|
|
|
estate->es_rowMarks = NIL;
|
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
estate->es_processed = 0;
|
|
|
|
estate->es_lastoid = InvalidOid;
|
|
|
|
|
2011-02-27 19:43:29 +01:00
|
|
|
estate->es_top_eflags = 0;
|
|
|
|
estate->es_instrument = 0;
|
|
|
|
estate->es_finished = false;
|
2002-12-15 17:17:59 +01:00
|
|
|
|
|
|
|
estate->es_exprcontexts = NIL;
|
|
|
|
|
2007-02-27 02:11:26 +01:00
|
|
|
estate->es_subplanstates = NIL;
|
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
estate->es_auxmodifytables = NIL;
|
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
estate->es_per_tuple_exprcontext = NULL;
|
|
|
|
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
estate->es_epqTuple = NULL;
|
|
|
|
estate->es_epqTupleSet = NULL;
|
|
|
|
estate->es_epqScanDone = NULL;
|
2017-02-22 07:45:17 +01:00
|
|
|
estate->es_sourceText = NULL;
|
2002-12-15 17:17:59 +01:00
|
|
|
|
2017-10-27 16:04:01 +02:00
|
|
|
estate->es_use_parallel_mode = false;
|
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
/*
|
|
|
|
* Return the executor state structure
|
|
|
|
*/
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
|
|
|
|
return estate;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
* FreeExecutorState
|
|
|
|
*
|
|
|
|
* Release an EState along with all remaining working storage.
|
|
|
|
*
|
|
|
|
* Note: this is not responsible for releasing non-memory resources,
|
|
|
|
* such as open relations or buffer pins. But it will shut down any
|
|
|
|
* still-active ExprContexts within the EState. That is sufficient
|
|
|
|
* cleanup for situations where the EState has only been used for expression
|
|
|
|
* evaluation, and not to run a complete Plan.
|
|
|
|
*
|
|
|
|
* This can be called in any memory context ... so long as it's not one
|
|
|
|
* of the ones to be freed.
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
FreeExecutorState(EState *estate)
|
|
|
|
{
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Shut down and free any remaining ExprContexts. We do this explicitly
|
|
|
|
* to ensure that any remaining shutdown callbacks get called (since they
|
|
|
|
* might need to release resources that aren't simply memory within the
|
|
|
|
* per-query memory context).
|
2002-12-15 17:17:59 +01:00
|
|
|
*/
|
|
|
|
while (estate->es_exprcontexts)
|
|
|
|
{
|
2004-08-29 07:07:03 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* XXX: seems there ought to be a faster way to implement this than
|
|
|
|
* repeated list_delete(), no?
|
2004-05-26 06:41:50 +02:00
|
|
|
*/
|
2009-07-18 21:15:42 +02:00
|
|
|
FreeExprContext((ExprContext *) linitial(estate->es_exprcontexts),
|
|
|
|
true);
|
2002-12-15 17:17:59 +01:00
|
|
|
/* FreeExprContext removed the list link for us */
|
|
|
|
}
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
/*
|
|
|
|
* Free the per-query memory context, thereby releasing all working
|
2007-02-27 02:11:26 +01:00
|
|
|
* memory, including the EState node itself.
|
2002-12-15 17:17:59 +01:00
|
|
|
*/
|
2007-02-27 02:11:26 +01:00
|
|
|
MemoryContextDelete(estate->es_query_cxt);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
2002-12-15 17:17:59 +01:00
|
|
|
* CreateExprContext
|
|
|
|
*
|
|
|
|
* Create a context for expression evaluation within an EState.
|
|
|
|
*
|
|
|
|
* An executor run may require multiple ExprContexts (we usually make one
|
|
|
|
* for each Plan node, and a separate one for per-output-tuple processing
|
|
|
|
* such as constraint checking). Each ExprContext has its own "per-tuple"
|
|
|
|
* memory context.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2002-12-15 17:17:59 +01:00
|
|
|
* Note we make no assumption about the caller's memory context.
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
2000-07-12 04:37:39 +02:00
|
|
|
ExprContext *
|
2002-12-15 17:17:59 +01:00
|
|
|
CreateExprContext(EState *estate)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2002-12-15 17:17:59 +01:00
|
|
|
ExprContext *econtext;
|
|
|
|
MemoryContext oldcontext;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
/* Create the ExprContext node within the per-query memory context */
|
|
|
|
oldcontext = MemoryContextSwitchTo(estate->es_query_cxt);
|
|
|
|
|
|
|
|
econtext = makeNode(ExprContext);
|
|
|
|
|
|
|
|
/* Initialize fields of ExprContext */
|
|
|
|
econtext->ecxt_scantuple = NULL;
|
2000-07-12 04:37:39 +02:00
|
|
|
econtext->ecxt_innertuple = NULL;
|
|
|
|
econtext->ecxt_outertuple = NULL;
|
2002-12-15 17:17:59 +01:00
|
|
|
|
|
|
|
econtext->ecxt_per_query_memory = estate->es_query_cxt;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2000-07-12 04:37:39 +02:00
|
|
|
/*
|
2002-12-15 17:17:59 +01:00
|
|
|
* Create working memory for expression evaluation in this context.
|
2000-07-12 04:37:39 +02:00
|
|
|
*/
|
|
|
|
econtext->ecxt_per_tuple_memory =
|
2002-12-15 17:17:59 +01:00
|
|
|
AllocSetContextCreate(estate->es_query_cxt,
|
|
|
|
"ExprContext",
|
Add macros to make AllocSetContextCreate() calls simpler and safer.
I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls
had typos in the context-sizing parameters. While none of these led to
especially significant problems, they did create minor inefficiencies,
and it's now clear that expecting people to copy-and-paste those calls
accurately is not a great idea. Let's reduce the risk of future errors
by introducing single macros that encapsulate the common use-cases.
Three such macros are enough to cover all but two special-purpose contexts;
those two calls can be left as-is, I think.
While this patch doesn't in itself improve matters for third-party
extensions, it doesn't break anything for them either, and they can
gradually adopt the simplified notation over time.
In passing, change TopMemoryContext to use the default allocation
parameters. Formerly it could only be extended 8K at a time. That was
probably reasonable when this code was written; but nowadays we create
many more contexts than we did then, so that it's not unusual to have a
couple hundred K in TopMemoryContext, even without considering various
dubious code that sticks other things there. There seems no good reason
not to let it use growing blocks like most other contexts.
Back-patch to 9.6, mostly because that's still close enough to HEAD that
it's easy to do so, and keeping the branches in sync can be expected to
avoid some future back-patching pain. The bugs fixed by these changes
don't seem to be significant enough to justify fixing them further back.
Discussion: <21072.1472321324@sss.pgh.pa.us>
2016-08-27 23:50:38 +02:00
|
|
|
ALLOCSET_DEFAULT_SIZES);
|
2002-12-15 17:17:59 +01:00
|
|
|
|
|
|
|
econtext->ecxt_param_exec_vals = estate->es_param_exec_vals;
|
|
|
|
econtext->ecxt_param_list_info = estate->es_param_list_info;
|
|
|
|
|
2000-07-12 04:37:39 +02:00
|
|
|
econtext->ecxt_aggvalues = NULL;
|
|
|
|
econtext->ecxt_aggnulls = NULL;
|
2002-12-15 17:17:59 +01:00
|
|
|
|
2004-03-17 21:48:43 +01:00
|
|
|
econtext->caseValue_datum = (Datum) 0;
|
|
|
|
econtext->caseValue_isNull = true;
|
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
econtext->domainValue_datum = (Datum) 0;
|
|
|
|
econtext->domainValue_isNull = true;
|
|
|
|
|
|
|
|
econtext->ecxt_estate = estate;
|
|
|
|
|
2002-05-12 22:10:05 +02:00
|
|
|
econtext->ecxt_callbacks = NULL;
|
2000-07-12 04:37:39 +02:00
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Link the ExprContext into the EState to ensure it is shut down when the
|
|
|
|
* EState is freed. Because we use lcons(), shutdowns will occur in
|
|
|
|
* reverse order of creation, which may not be essential but can't hurt.
|
2002-12-15 17:17:59 +01:00
|
|
|
*/
|
|
|
|
estate->es_exprcontexts = lcons(econtext, estate->es_exprcontexts);
|
|
|
|
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
|
2000-07-12 04:37:39 +02:00
|
|
|
return econtext;
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2006-08-04 23:33:36 +02:00
|
|
|
/* ----------------
|
|
|
|
* CreateStandaloneExprContext
|
|
|
|
*
|
|
|
|
* Create a context for standalone expression evaluation.
|
|
|
|
*
|
|
|
|
* An ExprContext made this way can be used for evaluation of expressions
|
|
|
|
* that contain no Params, subplans, or Var references (it might work to
|
|
|
|
* put tuple references into the scantuple field, but it seems unwise).
|
|
|
|
*
|
|
|
|
* The ExprContext struct is allocated in the caller's current memory
|
|
|
|
* context, which also becomes its "per query" context.
|
|
|
|
*
|
|
|
|
* It is caller's responsibility to free the ExprContext when done,
|
|
|
|
* or at least ensure that any shutdown callbacks have been called
|
|
|
|
* (ReScanExprContext() is suitable). Otherwise, non-memory resources
|
|
|
|
* might be leaked.
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
ExprContext *
|
|
|
|
CreateStandaloneExprContext(void)
|
|
|
|
{
|
|
|
|
ExprContext *econtext;
|
|
|
|
|
|
|
|
/* Create the ExprContext node within the caller's memory context */
|
|
|
|
econtext = makeNode(ExprContext);
|
|
|
|
|
|
|
|
/* Initialize fields of ExprContext */
|
|
|
|
econtext->ecxt_scantuple = NULL;
|
|
|
|
econtext->ecxt_innertuple = NULL;
|
|
|
|
econtext->ecxt_outertuple = NULL;
|
|
|
|
|
|
|
|
econtext->ecxt_per_query_memory = CurrentMemoryContext;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create working memory for expression evaluation in this context.
|
|
|
|
*/
|
|
|
|
econtext->ecxt_per_tuple_memory =
|
|
|
|
AllocSetContextCreate(CurrentMemoryContext,
|
|
|
|
"ExprContext",
|
Add macros to make AllocSetContextCreate() calls simpler and safer.
I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls
had typos in the context-sizing parameters. While none of these led to
especially significant problems, they did create minor inefficiencies,
and it's now clear that expecting people to copy-and-paste those calls
accurately is not a great idea. Let's reduce the risk of future errors
by introducing single macros that encapsulate the common use-cases.
Three such macros are enough to cover all but two special-purpose contexts;
those two calls can be left as-is, I think.
While this patch doesn't in itself improve matters for third-party
extensions, it doesn't break anything for them either, and they can
gradually adopt the simplified notation over time.
In passing, change TopMemoryContext to use the default allocation
parameters. Formerly it could only be extended 8K at a time. That was
probably reasonable when this code was written; but nowadays we create
many more contexts than we did then, so that it's not unusual to have a
couple hundred K in TopMemoryContext, even without considering various
dubious code that sticks other things there. There seems no good reason
not to let it use growing blocks like most other contexts.
Back-patch to 9.6, mostly because that's still close enough to HEAD that
it's easy to do so, and keeping the branches in sync can be expected to
avoid some future back-patching pain. The bugs fixed by these changes
don't seem to be significant enough to justify fixing them further back.
Discussion: <21072.1472321324@sss.pgh.pa.us>
2016-08-27 23:50:38 +02:00
|
|
|
ALLOCSET_DEFAULT_SIZES);
|
2006-08-04 23:33:36 +02:00
|
|
|
|
|
|
|
econtext->ecxt_param_exec_vals = NULL;
|
|
|
|
econtext->ecxt_param_list_info = NULL;
|
|
|
|
|
|
|
|
econtext->ecxt_aggvalues = NULL;
|
|
|
|
econtext->ecxt_aggnulls = NULL;
|
|
|
|
|
|
|
|
econtext->caseValue_datum = (Datum) 0;
|
|
|
|
econtext->caseValue_isNull = true;
|
|
|
|
|
|
|
|
econtext->domainValue_datum = (Datum) 0;
|
|
|
|
econtext->domainValue_isNull = true;
|
|
|
|
|
|
|
|
econtext->ecxt_estate = NULL;
|
|
|
|
|
|
|
|
econtext->ecxt_callbacks = NULL;
|
|
|
|
|
|
|
|
return econtext;
|
|
|
|
}
|
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
/* ----------------
|
|
|
|
* FreeExprContext
|
|
|
|
*
|
|
|
|
* Free an expression context, including calling any remaining
|
|
|
|
* shutdown callbacks.
|
|
|
|
*
|
|
|
|
* Since we free the temporary context used for expression evaluation,
|
|
|
|
* any previously computed pass-by-reference expression result will go away!
|
|
|
|
*
|
2009-07-18 21:15:42 +02:00
|
|
|
* If isCommit is false, we are being called in error cleanup, and should
|
2014-05-06 18:12:18 +02:00
|
|
|
* not call callbacks but only release memory. (It might be better to call
|
2009-07-18 21:15:42 +02:00
|
|
|
* the callbacks and pass the isCommit flag to them, but that would require
|
|
|
|
* more invasive code changes than currently seems justified.)
|
|
|
|
*
|
2002-12-15 17:17:59 +01:00
|
|
|
* Note we make no assumption about the caller's memory context.
|
|
|
|
* ----------------
|
2000-07-12 04:37:39 +02:00
|
|
|
*/
|
|
|
|
void
|
2009-07-18 21:15:42 +02:00
|
|
|
FreeExprContext(ExprContext *econtext, bool isCommit)
|
2000-07-12 04:37:39 +02:00
|
|
|
{
|
2002-12-15 17:17:59 +01:00
|
|
|
EState *estate;
|
|
|
|
|
2002-05-12 22:10:05 +02:00
|
|
|
/* Call any registered callbacks */
|
2009-07-18 21:15:42 +02:00
|
|
|
ShutdownExprContext(econtext, isCommit);
|
2002-05-12 22:10:05 +02:00
|
|
|
/* And clean up the memory used */
|
2000-07-12 04:37:39 +02:00
|
|
|
MemoryContextDelete(econtext->ecxt_per_tuple_memory);
|
2006-08-04 23:33:36 +02:00
|
|
|
/* Unlink self from owning EState, if any */
|
2002-12-15 17:17:59 +01:00
|
|
|
estate = econtext->ecxt_estate;
|
2006-08-04 23:33:36 +02:00
|
|
|
if (estate)
|
|
|
|
estate->es_exprcontexts = list_delete_ptr(estate->es_exprcontexts,
|
|
|
|
econtext);
|
2002-12-15 17:17:59 +01:00
|
|
|
/* And delete the ExprContext node */
|
2000-07-12 04:37:39 +02:00
|
|
|
pfree(econtext);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2003-12-18 21:21:37 +01:00
|
|
|
/*
|
|
|
|
* ReScanExprContext
|
|
|
|
*
|
|
|
|
* Reset an expression context in preparation for a rescan of its
|
2014-05-06 18:12:18 +02:00
|
|
|
* plan node. This requires calling any registered shutdown callbacks,
|
2003-12-18 21:21:37 +01:00
|
|
|
* since any partially complete set-returning-functions must be canceled.
|
|
|
|
*
|
|
|
|
* Note we make no assumption about the caller's memory context.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ReScanExprContext(ExprContext *econtext)
|
|
|
|
{
|
|
|
|
/* Call any registered callbacks */
|
2009-07-18 21:15:42 +02:00
|
|
|
ShutdownExprContext(econtext, true);
|
2003-12-18 21:21:37 +01:00
|
|
|
/* And clean up the memory used */
|
|
|
|
MemoryContextReset(econtext->ecxt_per_tuple_memory);
|
|
|
|
}
|
|
|
|
|
2001-01-22 01:50:07 +01:00
|
|
|
/*
|
|
|
|
* Build a per-output-tuple ExprContext for an EState.
|
|
|
|
*
|
2002-12-15 17:17:59 +01:00
|
|
|
* This is normally invoked via GetPerTupleExprContext() macro,
|
|
|
|
* not directly.
|
2001-01-22 01:50:07 +01:00
|
|
|
*/
|
|
|
|
ExprContext *
|
|
|
|
MakePerTupleExprContext(EState *estate)
|
|
|
|
{
|
|
|
|
if (estate->es_per_tuple_exprcontext == NULL)
|
2002-12-15 17:17:59 +01:00
|
|
|
estate->es_per_tuple_exprcontext = CreateExprContext(estate);
|
2001-01-22 01:50:07 +01:00
|
|
|
|
|
|
|
return estate->es_per_tuple_exprcontext;
|
|
|
|
}
|
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* ----------------------------------------------------------------
|
2002-12-15 17:17:59 +01:00
|
|
|
* miscellaneous node-init support functions
|
|
|
|
*
|
|
|
|
* Note: all of these are expected to be called with CurrentMemoryContext
|
|
|
|
* equal to the per-query memory context.
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
/* ----------------
|
|
|
|
* ExecAssignExprContext
|
|
|
|
*
|
2014-05-06 18:12:18 +02:00
|
|
|
* This initializes the ps_ExprContext field. It is only necessary
|
2002-12-15 17:17:59 +01:00
|
|
|
* to do this for nodes which use ExecQual or ExecProject
|
2003-08-04 02:43:34 +02:00
|
|
|
* because those routines require an econtext. Other nodes that
|
2002-12-15 17:17:59 +01:00
|
|
|
* don't have to evaluate expressions don't need to do this.
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
2003-08-08 23:42:59 +02:00
|
|
|
ExecAssignExprContext(EState *estate, PlanState *planstate)
|
2002-12-15 17:17:59 +01:00
|
|
|
{
|
|
|
|
planstate->ps_ExprContext = CreateExprContext(estate);
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* ExecAssignResultType
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
2006-06-16 20:42:24 +02:00
|
|
|
ExecAssignResultType(PlanState *planstate, TupleDesc tupDesc)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2002-12-05 16:50:39 +01:00
|
|
|
TupleTableSlot *slot = planstate->ps_ResultTupleSlot;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2006-06-16 20:42:24 +02:00
|
|
|
ExecSetSlotDescriptor(slot, tupDesc);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* ExecAssignResultTypeFromTL
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
2003-08-08 23:42:59 +02:00
|
|
|
ExecAssignResultTypeFromTL(PlanState *planstate)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2004-01-22 03:23:21 +01:00
|
|
|
bool hasoid;
|
2000-09-12 23:07:18 +02:00
|
|
|
TupleDesc tupDesc;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2004-01-22 03:23:21 +01:00
|
|
|
if (ExecContextForcesOids(planstate, &hasoid))
|
|
|
|
{
|
|
|
|
/* context forces OID choice; hasoid is now set correctly */
|
|
|
|
}
|
2003-01-23 06:10:41 +01:00
|
|
|
else
|
2002-09-02 03:05:06 +02:00
|
|
|
{
|
2004-01-22 03:23:21 +01:00
|
|
|
/* given free choice, don't leave space for OIDs in result tuples */
|
|
|
|
hasoid = false;
|
2002-09-02 03:05:06 +02:00
|
|
|
}
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2002-12-05 16:50:39 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* ExecTypeFromTL needs the parse-time representation of the tlist, not a
|
2014-05-06 18:12:18 +02:00
|
|
|
* list of ExprStates. This is good because some plan nodes don't bother
|
2005-10-15 04:49:52 +02:00
|
|
|
* to set up planstate->targetlist ...
|
2002-12-05 16:50:39 +01:00
|
|
|
*/
|
|
|
|
tupDesc = ExecTypeFromTL(planstate->plan->targetlist, hasoid);
|
2006-06-16 20:42:24 +02:00
|
|
|
ExecAssignResultType(planstate, tupDesc);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* ExecGetResultType
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
TupleDesc
|
2003-08-08 23:42:59 +02:00
|
|
|
ExecGetResultType(PlanState *planstate)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2002-12-05 16:50:39 +01:00
|
|
|
TupleTableSlot *slot = planstate->ps_ResultTupleSlot;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2005-03-16 22:38:10 +01:00
|
|
|
return slot->tts_tupleDescriptor;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2009-04-03 00:39:30 +02:00
|
|
|
|
2003-01-12 05:03:34 +01:00
|
|
|
/* ----------------
|
|
|
|
* ExecAssignProjectionInfo
|
|
|
|
*
|
|
|
|
* forms the projection information from the node's targetlist
|
2007-02-02 01:07:03 +01:00
|
|
|
*
|
|
|
|
* Notes for inputDesc are same as for ExecBuildProjectionInfo: supply it
|
|
|
|
* for a relation-scan node, can pass NULL for upper-level nodes
|
2003-01-12 05:03:34 +01:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
2007-02-02 01:07:03 +01:00
|
|
|
ExecAssignProjectionInfo(PlanState *planstate,
|
|
|
|
TupleDesc inputDesc)
|
2003-01-12 05:03:34 +01:00
|
|
|
{
|
|
|
|
planstate->ps_ProjInfo =
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ExecBuildProjectionInfo(planstate->plan->targetlist,
|
2003-01-12 05:03:34 +01:00
|
|
|
planstate->ps_ExprContext,
|
2007-02-02 01:07:03 +01:00
|
|
|
planstate->ps_ResultTupleSlot,
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
planstate,
|
2007-02-02 01:07:03 +01:00
|
|
|
inputDesc);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-11-25 16:49:17 +01:00
|
|
|
/* ----------------
|
|
|
|
* ExecConditionalAssignProjectionInfo
|
|
|
|
*
|
|
|
|
* as ExecAssignProjectionInfo, but store NULL rather than building projection
|
|
|
|
* info if no projection is required
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ExecConditionalAssignProjectionInfo(PlanState *planstate, TupleDesc inputDesc,
|
|
|
|
Index varno)
|
|
|
|
{
|
|
|
|
if (tlist_matches_tupdesc(planstate,
|
|
|
|
planstate->plan->targetlist,
|
|
|
|
varno,
|
|
|
|
inputDesc))
|
|
|
|
planstate->ps_ProjInfo = NULL;
|
|
|
|
else
|
|
|
|
ExecAssignProjectionInfo(planstate, inputDesc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
tlist_matches_tupdesc(PlanState *ps, List *tlist, Index varno, TupleDesc tupdesc)
|
|
|
|
{
|
|
|
|
int numattrs = tupdesc->natts;
|
|
|
|
int attrno;
|
|
|
|
bool hasoid;
|
|
|
|
ListCell *tlist_item = list_head(tlist);
|
|
|
|
|
|
|
|
/* Check the tlist attributes */
|
|
|
|
for (attrno = 1; attrno <= numattrs; attrno++)
|
|
|
|
{
|
|
|
|
Form_pg_attribute att_tup = TupleDescAttr(tupdesc, attrno - 1);
|
|
|
|
Var *var;
|
|
|
|
|
|
|
|
if (tlist_item == NULL)
|
|
|
|
return false; /* tlist too short */
|
|
|
|
var = (Var *) ((TargetEntry *) lfirst(tlist_item))->expr;
|
|
|
|
if (!var || !IsA(var, Var))
|
|
|
|
return false; /* tlist item not a Var */
|
|
|
|
/* if these Asserts fail, planner messed up */
|
|
|
|
Assert(var->varno == varno);
|
|
|
|
Assert(var->varlevelsup == 0);
|
|
|
|
if (var->varattno != attrno)
|
|
|
|
return false; /* out of order */
|
|
|
|
if (att_tup->attisdropped)
|
|
|
|
return false; /* table contains dropped columns */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: usually the Var's type should match the tupdesc exactly, but
|
|
|
|
* in situations involving unions of columns that have different
|
|
|
|
* typmods, the Var may have come from above the union and hence have
|
|
|
|
* typmod -1. This is a legitimate situation since the Var still
|
|
|
|
* describes the column, just not as exactly as the tupdesc does. We
|
|
|
|
* could change the planner to prevent it, but it'd then insert
|
|
|
|
* projection steps just to convert from specific typmod to typmod -1,
|
|
|
|
* which is pretty silly.
|
|
|
|
*/
|
|
|
|
if (var->vartype != att_tup->atttypid ||
|
|
|
|
(var->vartypmod != att_tup->atttypmod &&
|
|
|
|
var->vartypmod != -1))
|
|
|
|
return false; /* type mismatch */
|
|
|
|
|
|
|
|
tlist_item = lnext(tlist_item);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tlist_item)
|
|
|
|
return false; /* tlist too long */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the plan context requires a particular hasoid setting, then that has
|
|
|
|
* to match, too.
|
|
|
|
*/
|
|
|
|
if (ExecContextForcesOids(ps, &hasoid) &&
|
|
|
|
hasoid != tupdesc->tdhasoid)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
1999-03-20 02:13:22 +01:00
|
|
|
/* ----------------
|
|
|
|
* ExecFreeExprContext
|
2002-12-15 17:17:59 +01:00
|
|
|
*
|
2005-04-23 23:32:34 +02:00
|
|
|
* A plan node's ExprContext should be freed explicitly during executor
|
|
|
|
* shutdown because there may be shutdown callbacks to call. (Other resources
|
|
|
|
* made by the above routines, such as projection info, don't need to be freed
|
2002-12-15 17:17:59 +01:00
|
|
|
* explicitly because they're just memory in the per-query memory context.)
|
2005-04-23 23:32:34 +02:00
|
|
|
*
|
|
|
|
* However ... there is no particular need to do it during ExecEndNode,
|
|
|
|
* because FreeExecutorState will free any remaining ExprContexts within
|
2014-05-06 18:12:18 +02:00
|
|
|
* the EState. Letting FreeExecutorState do it allows the ExprContexts to
|
2005-04-23 23:32:34 +02:00
|
|
|
* be freed in reverse order of creation, rather than order of creation as
|
|
|
|
* will happen if we delete them here, which saves O(N^2) work in the list
|
|
|
|
* cleanup inside FreeExprContext.
|
1999-03-20 02:13:22 +01:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
2003-08-08 23:42:59 +02:00
|
|
|
ExecFreeExprContext(PlanState *planstate)
|
1999-03-20 02:13:22 +01:00
|
|
|
{
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Per above discussion, don't actually delete the ExprContext. We do
|
|
|
|
* unlink it from the plan node, though.
|
1999-03-20 02:13:22 +01:00
|
|
|
*/
|
2002-12-05 16:50:39 +01:00
|
|
|
planstate->ps_ExprContext = NULL;
|
1999-03-20 02:13:22 +01:00
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* ----------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* the following scan type support functions are for
|
|
|
|
* those nodes which are stubborn and return tuples in
|
|
|
|
* their Scan tuple slot instead of their Result tuple
|
2014-05-06 18:12:18 +02:00
|
|
|
* slot.. luck fur us, these nodes do not do projections
|
1997-09-07 07:04:48 +02:00
|
|
|
* so we don't have to worry about getting the ProjectionInfo
|
|
|
|
* right for them... -cim 6/3/91
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* ExecAssignScanType
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
2006-06-16 20:42:24 +02:00
|
|
|
ExecAssignScanType(ScanState *scanstate, TupleDesc tupDesc)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2002-12-05 16:50:39 +01:00
|
|
|
TupleTableSlot *slot = scanstate->ss_ScanTupleSlot;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2006-06-16 20:42:24 +02:00
|
|
|
ExecSetSlotDescriptor(slot, tupDesc);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* ExecAssignScanTypeFromOuterPlan
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
2003-08-08 23:42:59 +02:00
|
|
|
ExecAssignScanTypeFromOuterPlan(ScanState *scanstate)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2002-12-05 16:50:39 +01:00
|
|
|
PlanState *outerPlan;
|
1997-09-08 04:41:22 +02:00
|
|
|
TupleDesc tupDesc;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-12-05 16:50:39 +01:00
|
|
|
outerPlan = outerPlanState(scanstate);
|
2003-05-05 19:57:47 +02:00
|
|
|
tupDesc = ExecGetResultType(outerPlan);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2006-06-16 20:42:24 +02:00
|
|
|
ExecAssignScanType(scanstate, tupDesc);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-12-02 21:03:42 +01:00
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* Scan node support
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2005-12-03 06:51:03 +01:00
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecRelationIsTargetRelation
|
|
|
|
*
|
|
|
|
* Detect whether a relation (identified by rangetable index)
|
|
|
|
* is one of the target relations of the query.
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
ExecRelationIsTargetRelation(EState *estate, Index scanrelid)
|
|
|
|
{
|
|
|
|
ResultRelInfo *resultRelInfos;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
resultRelInfos = estate->es_result_relations;
|
|
|
|
for (i = 0; i < estate->es_num_result_relations; i++)
|
|
|
|
{
|
|
|
|
if (resultRelInfos[i].ri_RangeTableIndex == scanrelid)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2005-12-02 21:03:42 +01:00
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecOpenScanRelation
|
|
|
|
*
|
|
|
|
* Open the heap relation to be scanned by a base-level scan plan node.
|
|
|
|
* This should be called during the node's ExecInit routine.
|
|
|
|
*
|
|
|
|
* By default, this acquires AccessShareLock on the relation. However,
|
|
|
|
* if the relation was already locked by InitPlan, we don't need to acquire
|
|
|
|
* any additional lock. This saves trips to the shared lock manager.
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
Relation
|
2013-04-27 23:48:57 +02:00
|
|
|
ExecOpenScanRelation(EState *estate, Index scanrelid, int eflags)
|
2005-12-02 21:03:42 +01:00
|
|
|
{
|
2013-04-27 23:48:57 +02:00
|
|
|
Relation rel;
|
2005-12-02 21:03:42 +01:00
|
|
|
Oid reloid;
|
|
|
|
LOCKMODE lockmode;
|
|
|
|
|
|
|
|
/*
|
2007-07-31 18:36:07 +02:00
|
|
|
* Determine the lock type we need. First, scan to see if target relation
|
|
|
|
* is a result relation. If not, check if it's a FOR UPDATE/FOR SHARE
|
|
|
|
* relation. In either of those cases, we got the lock already.
|
2005-12-02 21:03:42 +01:00
|
|
|
*/
|
|
|
|
lockmode = AccessShareLock;
|
2007-07-27 21:09:04 +02:00
|
|
|
if (ExecRelationIsTargetRelation(estate, scanrelid))
|
|
|
|
lockmode = NoLock;
|
2007-07-31 18:36:07 +02:00
|
|
|
else
|
2005-12-02 21:03:42 +01:00
|
|
|
{
|
Add support for doing late row locking in FDWs.
Previously, FDWs could only do "early row locking", that is lock a row as
soon as it's fetched, even though local restriction/join conditions might
discard the row later. This patch adds callbacks that allow FDWs to do
late locking in the same way that it's done for regular tables.
To make use of this feature, an FDW must support the "ctid" column as a
unique row identifier. Currently, since ctid has to be of type TID,
the feature is of limited use, though in principle it could be used by
postgres_fdw. We may eventually allow FDWs to specify another data type
for ctid, which would make it possible for more FDWs to use this feature.
This commit does not modify postgres_fdw to use late locking. We've
tested some prototype code for that, but it's not in committable shape,
and besides it's quite unclear whether it actually makes sense to do late
locking against a remote server. The extra round trips required are likely
to outweigh any benefit from improved concurrency.
Etsuro Fujita, reviewed by Ashutosh Bapat, and hacked up a lot by me
2015-05-12 20:10:10 +02:00
|
|
|
/* Keep this check in sync with InitPlan! */
|
|
|
|
ExecRowMark *erm = ExecFindRowMark(estate, scanrelid, true);
|
2005-12-02 21:03:42 +01:00
|
|
|
|
Add support for doing late row locking in FDWs.
Previously, FDWs could only do "early row locking", that is lock a row as
soon as it's fetched, even though local restriction/join conditions might
discard the row later. This patch adds callbacks that allow FDWs to do
late locking in the same way that it's done for regular tables.
To make use of this feature, an FDW must support the "ctid" column as a
unique row identifier. Currently, since ctid has to be of type TID,
the feature is of limited use, though in principle it could be used by
postgres_fdw. We may eventually allow FDWs to specify another data type
for ctid, which would make it possible for more FDWs to use this feature.
This commit does not modify postgres_fdw to use late locking. We've
tested some prototype code for that, but it's not in committable shape,
and besides it's quite unclear whether it actually makes sense to do late
locking against a remote server. The extra round trips required are likely
to outweigh any benefit from improved concurrency.
Etsuro Fujita, reviewed by Ashutosh Bapat, and hacked up a lot by me
2015-05-12 20:10:10 +02:00
|
|
|
if (erm != NULL && erm->relation != NULL)
|
|
|
|
lockmode = NoLock;
|
2005-12-02 21:03:42 +01:00
|
|
|
}
|
|
|
|
|
2013-04-27 23:48:57 +02:00
|
|
|
/* Open the relation and acquire lock as needed */
|
2007-02-22 23:00:26 +01:00
|
|
|
reloid = getrelid(scanrelid, estate->es_range_table);
|
2013-04-27 23:48:57 +02:00
|
|
|
rel = heap_open(reloid, lockmode);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Complain if we're attempting a scan of an unscannable relation, except
|
|
|
|
* when the query won't actually be run. This is a slightly klugy place
|
|
|
|
* to do this, perhaps, but there is no better place.
|
|
|
|
*/
|
|
|
|
if ((eflags & (EXEC_FLAG_EXPLAIN_ONLY | EXEC_FLAG_WITH_NO_DATA)) == 0 &&
|
|
|
|
!RelationIsScannable(rel))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
|
|
|
|
errmsg("materialized view \"%s\" has not been populated",
|
|
|
|
RelationGetRelationName(rel)),
|
|
|
|
errhint("Use the REFRESH MATERIALIZED VIEW command.")));
|
|
|
|
|
|
|
|
return rel;
|
2005-12-02 21:03:42 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* ExecCloseScanRelation
|
|
|
|
*
|
|
|
|
* Close the heap relation scanned by a base-level scan plan node.
|
|
|
|
* This should be called during the node's ExecEnd routine.
|
|
|
|
*
|
|
|
|
* Currently, we do not release the lock acquired by ExecOpenScanRelation.
|
|
|
|
* This lock should be held till end of transaction. (There is a faction
|
|
|
|
* that considers this too much locking, however.)
|
|
|
|
*
|
|
|
|
* If we did want to release the lock, we'd have to repeat the logic in
|
|
|
|
* ExecOpenScanRelation in order to figure out what to release.
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ExecCloseScanRelation(Relation scanrel)
|
|
|
|
{
|
|
|
|
heap_close(scanrel, NoLock);
|
|
|
|
}
|
|
|
|
|
2003-02-09 01:30:41 +01:00
|
|
|
/*
|
|
|
|
* UpdateChangedParamSet
|
|
|
|
* Add changed parameters to a plan node's chgParam set
|
|
|
|
*/
|
1998-02-26 05:46:47 +01:00
|
|
|
void
|
2003-08-08 23:42:59 +02:00
|
|
|
UpdateChangedParamSet(PlanState *node, Bitmapset *newchg)
|
1998-02-13 04:26:53 +01:00
|
|
|
{
|
2003-02-09 01:30:41 +01:00
|
|
|
Bitmapset *parmset;
|
1998-02-26 05:46:47 +01:00
|
|
|
|
2003-02-09 01:30:41 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* The plan node only depends on params listed in its allParam set. Don't
|
|
|
|
* include anything else into its chgParam set.
|
2003-02-09 01:30:41 +01:00
|
|
|
*/
|
|
|
|
parmset = bms_intersect(node->plan->allParam, newchg);
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2003-02-09 01:30:41 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Keep node->chgParam == NULL if there's not actually any members; this
|
|
|
|
* allows the simplest possible tests in executor node files.
|
2003-02-09 01:30:41 +01:00
|
|
|
*/
|
|
|
|
if (!bms_is_empty(parmset))
|
|
|
|
node->chgParam = bms_join(node->chgParam, parmset);
|
|
|
|
else
|
|
|
|
bms_free(parmset);
|
1998-02-13 04:26:53 +01:00
|
|
|
}
|
2002-05-12 22:10:05 +02:00
|
|
|
|
2017-04-18 19:20:59 +02:00
|
|
|
/*
|
|
|
|
* executor_errposition
|
|
|
|
* Report an execution-time cursor position, if possible.
|
|
|
|
*
|
|
|
|
* This is expected to be used within an ereport() call. The return value
|
|
|
|
* is a dummy (always 0, in fact).
|
|
|
|
*
|
|
|
|
* The locations stored in parsetrees are byte offsets into the source string.
|
|
|
|
* We have to convert them to 1-based character indexes for reporting to
|
|
|
|
* clients. (We do things this way to avoid unnecessary overhead in the
|
|
|
|
* normal non-error case: computing character indexes would be much more
|
|
|
|
* expensive than storing token offsets.)
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
executor_errposition(EState *estate, int location)
|
|
|
|
{
|
|
|
|
int pos;
|
|
|
|
|
|
|
|
/* No-op if location was not provided */
|
|
|
|
if (location < 0)
|
|
|
|
return 0;
|
|
|
|
/* Can't do anything if source text is not available */
|
|
|
|
if (estate == NULL || estate->es_sourceText == NULL)
|
|
|
|
return 0;
|
|
|
|
/* Convert offset to character number */
|
|
|
|
pos = pg_mbstrlen_with_len(estate->es_sourceText, location) + 1;
|
|
|
|
/* And pass it to the ereport mechanism */
|
|
|
|
return errposition(pos);
|
|
|
|
}
|
|
|
|
|
2002-05-12 22:10:05 +02:00
|
|
|
/*
|
|
|
|
* Register a shutdown callback in an ExprContext.
|
|
|
|
*
|
|
|
|
* Shutdown callbacks will be called (in reverse order of registration)
|
|
|
|
* when the ExprContext is deleted or rescanned. This provides a hook
|
|
|
|
* for functions called in the context to do any cleanup needed --- it's
|
|
|
|
* particularly useful for functions returning sets. Note that the
|
|
|
|
* callback will *not* be called in the event that execution is aborted
|
|
|
|
* by an error.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
RegisterExprContextCallback(ExprContext *econtext,
|
|
|
|
ExprContextCallbackFunction function,
|
|
|
|
Datum arg)
|
|
|
|
{
|
2002-09-04 22:31:48 +02:00
|
|
|
ExprContext_CB *ecxt_callback;
|
2002-05-12 22:10:05 +02:00
|
|
|
|
|
|
|
/* Save the info in appropriate memory context */
|
|
|
|
ecxt_callback = (ExprContext_CB *)
|
|
|
|
MemoryContextAlloc(econtext->ecxt_per_query_memory,
|
|
|
|
sizeof(ExprContext_CB));
|
|
|
|
|
|
|
|
ecxt_callback->function = function;
|
|
|
|
ecxt_callback->arg = arg;
|
|
|
|
|
|
|
|
/* link to front of list for appropriate execution order */
|
|
|
|
ecxt_callback->next = econtext->ecxt_callbacks;
|
|
|
|
econtext->ecxt_callbacks = ecxt_callback;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Deregister a shutdown callback in an ExprContext.
|
|
|
|
*
|
|
|
|
* Any list entries matching the function and arg will be removed.
|
|
|
|
* This can be used if it's no longer necessary to call the callback.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
UnregisterExprContextCallback(ExprContext *econtext,
|
|
|
|
ExprContextCallbackFunction function,
|
|
|
|
Datum arg)
|
|
|
|
{
|
2002-09-04 22:31:48 +02:00
|
|
|
ExprContext_CB **prev_callback;
|
|
|
|
ExprContext_CB *ecxt_callback;
|
2002-05-12 22:10:05 +02:00
|
|
|
|
|
|
|
prev_callback = &econtext->ecxt_callbacks;
|
|
|
|
|
|
|
|
while ((ecxt_callback = *prev_callback) != NULL)
|
|
|
|
{
|
|
|
|
if (ecxt_callback->function == function && ecxt_callback->arg == arg)
|
|
|
|
{
|
|
|
|
*prev_callback = ecxt_callback->next;
|
|
|
|
pfree(ecxt_callback);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
prev_callback = &ecxt_callback->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Call all the shutdown callbacks registered in an ExprContext.
|
|
|
|
*
|
|
|
|
* The callback list is emptied (important in case this is only a rescan
|
|
|
|
* reset, and not deletion of the ExprContext).
|
2009-07-18 21:15:42 +02:00
|
|
|
*
|
|
|
|
* If isCommit is false, just clean the callback list but don't call 'em.
|
|
|
|
* (See comment for FreeExprContext.)
|
2002-05-12 22:10:05 +02:00
|
|
|
*/
|
|
|
|
static void
|
2009-07-18 21:15:42 +02:00
|
|
|
ShutdownExprContext(ExprContext *econtext, bool isCommit)
|
2002-05-12 22:10:05 +02:00
|
|
|
{
|
2002-09-04 22:31:48 +02:00
|
|
|
ExprContext_CB *ecxt_callback;
|
2002-12-15 17:17:59 +01:00
|
|
|
MemoryContext oldcontext;
|
|
|
|
|
|
|
|
/* Fast path in normal case where there's nothing to do. */
|
|
|
|
if (econtext->ecxt_callbacks == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Call the callbacks in econtext's per-tuple context. This ensures that
|
|
|
|
* any memory they might leak will get cleaned up.
|
2002-12-15 17:17:59 +01:00
|
|
|
*/
|
|
|
|
oldcontext = MemoryContextSwitchTo(econtext->ecxt_per_tuple_memory);
|
2002-05-12 22:10:05 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Call each callback function in reverse registration order.
|
|
|
|
*/
|
|
|
|
while ((ecxt_callback = econtext->ecxt_callbacks) != NULL)
|
|
|
|
{
|
|
|
|
econtext->ecxt_callbacks = ecxt_callback->next;
|
2009-07-18 21:15:42 +02:00
|
|
|
if (isCommit)
|
2017-09-07 18:06:23 +02:00
|
|
|
ecxt_callback->function(ecxt_callback->arg);
|
2002-05-12 22:10:05 +02:00
|
|
|
pfree(ecxt_callback);
|
|
|
|
}
|
2002-12-15 17:17:59 +01:00
|
|
|
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
2002-05-12 22:10:05 +02:00
|
|
|
}
|
2017-03-21 14:48:04 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* ExecLockNonLeafAppendTables
|
|
|
|
*
|
|
|
|
* Locks, if necessary, the tables indicated by the RT indexes contained in
|
|
|
|
* the partitioned_rels list. These are the non-leaf tables in the partition
|
|
|
|
* tree controlled by a given Append or MergeAppend node.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ExecLockNonLeafAppendTables(List *partitioned_rels, EState *estate)
|
|
|
|
{
|
|
|
|
PlannedStmt *stmt = estate->es_plannedstmt;
|
2017-05-17 22:31:56 +02:00
|
|
|
ListCell *lc;
|
2017-03-21 14:48:04 +01:00
|
|
|
|
|
|
|
foreach(lc, partitioned_rels)
|
|
|
|
{
|
|
|
|
ListCell *l;
|
2017-05-17 22:31:56 +02:00
|
|
|
Index rti = lfirst_int(lc);
|
|
|
|
bool is_result_rel = false;
|
|
|
|
Oid relid = getrelid(rti, estate->es_range_table);
|
2017-03-21 14:48:04 +01:00
|
|
|
|
|
|
|
/* If this is a result relation, already locked in InitPlan */
|
|
|
|
foreach(l, stmt->nonleafResultRelations)
|
|
|
|
{
|
|
|
|
if (rti == lfirst_int(l))
|
|
|
|
{
|
|
|
|
is_result_rel = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Not a result relation; check if there is a RowMark that requires
|
|
|
|
* taking a RowShareLock on this rel.
|
|
|
|
*/
|
|
|
|
if (!is_result_rel)
|
|
|
|
{
|
|
|
|
PlanRowMark *rc = NULL;
|
|
|
|
|
|
|
|
foreach(l, stmt->rowMarks)
|
|
|
|
{
|
|
|
|
if (((PlanRowMark *) lfirst(l))->rti == rti)
|
|
|
|
{
|
|
|
|
rc = lfirst(l);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rc && RowMarkRequiresRowShareLock(rc->markType))
|
|
|
|
LockRelationOid(relid, RowShareLock);
|
|
|
|
else
|
|
|
|
LockRelationOid(relid, AccessShareLock);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* GetAttributeByName
|
|
|
|
* GetAttributeByNum
|
|
|
|
*
|
|
|
|
* These functions return the value of the requested attribute
|
|
|
|
* out of the given tuple Datum.
|
|
|
|
* C functions which take a tuple as an argument are expected
|
|
|
|
* to use these. Ex: overpaid(EMP) might call GetAttributeByNum().
|
|
|
|
* Note: these are actually rather slow because they do a typcache
|
|
|
|
* lookup on each call.
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
GetAttributeByName(HeapTupleHeader tuple, const char *attname, bool *isNull)
|
|
|
|
{
|
|
|
|
AttrNumber attrno;
|
|
|
|
Datum result;
|
|
|
|
Oid tupType;
|
|
|
|
int32 tupTypmod;
|
|
|
|
TupleDesc tupDesc;
|
|
|
|
HeapTupleData tmptup;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (attname == NULL)
|
|
|
|
elog(ERROR, "invalid attribute name");
|
|
|
|
|
|
|
|
if (isNull == NULL)
|
|
|
|
elog(ERROR, "a NULL isNull pointer was passed");
|
|
|
|
|
|
|
|
if (tuple == NULL)
|
|
|
|
{
|
|
|
|
/* Kinda bogus but compatible with old behavior... */
|
|
|
|
*isNull = true;
|
|
|
|
return (Datum) 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
tupType = HeapTupleHeaderGetTypeId(tuple);
|
|
|
|
tupTypmod = HeapTupleHeaderGetTypMod(tuple);
|
|
|
|
tupDesc = lookup_rowtype_tupdesc(tupType, tupTypmod);
|
|
|
|
|
|
|
|
attrno = InvalidAttrNumber;
|
|
|
|
for (i = 0; i < tupDesc->natts; i++)
|
|
|
|
{
|
2017-08-20 20:19:07 +02:00
|
|
|
Form_pg_attribute att = TupleDescAttr(tupDesc, i);
|
|
|
|
|
|
|
|
if (namestrcmp(&(att->attname), attname) == 0)
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
{
|
2017-08-20 20:19:07 +02:00
|
|
|
attrno = att->attnum;
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (attrno == InvalidAttrNumber)
|
|
|
|
elog(ERROR, "attribute \"%s\" does not exist", attname);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* heap_getattr needs a HeapTuple not a bare HeapTupleHeader. We set all
|
|
|
|
* the fields in the struct just in case user tries to inspect system
|
|
|
|
* columns.
|
|
|
|
*/
|
|
|
|
tmptup.t_len = HeapTupleHeaderGetDatumLength(tuple);
|
|
|
|
ItemPointerSetInvalid(&(tmptup.t_self));
|
|
|
|
tmptup.t_tableOid = InvalidOid;
|
|
|
|
tmptup.t_data = tuple;
|
|
|
|
|
|
|
|
result = heap_getattr(&tmptup,
|
|
|
|
attrno,
|
|
|
|
tupDesc,
|
|
|
|
isNull);
|
|
|
|
|
|
|
|
ReleaseTupleDesc(tupDesc);
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
GetAttributeByNum(HeapTupleHeader tuple,
|
|
|
|
AttrNumber attrno,
|
|
|
|
bool *isNull)
|
|
|
|
{
|
|
|
|
Datum result;
|
|
|
|
Oid tupType;
|
|
|
|
int32 tupTypmod;
|
|
|
|
TupleDesc tupDesc;
|
|
|
|
HeapTupleData tmptup;
|
|
|
|
|
|
|
|
if (!AttributeNumberIsValid(attrno))
|
|
|
|
elog(ERROR, "invalid attribute number %d", attrno);
|
|
|
|
|
|
|
|
if (isNull == NULL)
|
|
|
|
elog(ERROR, "a NULL isNull pointer was passed");
|
|
|
|
|
|
|
|
if (tuple == NULL)
|
|
|
|
{
|
|
|
|
/* Kinda bogus but compatible with old behavior... */
|
|
|
|
*isNull = true;
|
|
|
|
return (Datum) 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
tupType = HeapTupleHeaderGetTypeId(tuple);
|
|
|
|
tupTypmod = HeapTupleHeaderGetTypMod(tuple);
|
|
|
|
tupDesc = lookup_rowtype_tupdesc(tupType, tupTypmod);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* heap_getattr needs a HeapTuple not a bare HeapTupleHeader. We set all
|
|
|
|
* the fields in the struct just in case user tries to inspect system
|
|
|
|
* columns.
|
|
|
|
*/
|
|
|
|
tmptup.t_len = HeapTupleHeaderGetDatumLength(tuple);
|
|
|
|
ItemPointerSetInvalid(&(tmptup.t_self));
|
|
|
|
tmptup.t_tableOid = InvalidOid;
|
|
|
|
tmptup.t_data = tuple;
|
|
|
|
|
|
|
|
result = heap_getattr(&tmptup,
|
|
|
|
attrno,
|
|
|
|
tupDesc,
|
|
|
|
isNull);
|
|
|
|
|
|
|
|
ReleaseTupleDesc(tupDesc);
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Number of items in a tlist (including any resjunk items!)
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
ExecTargetListLength(List *targetlist)
|
|
|
|
{
|
|
|
|
/* This used to be more complex, but fjoins are dead */
|
|
|
|
return list_length(targetlist);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Number of items in a tlist, not including any resjunk items
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
ExecCleanTargetListLength(List *targetlist)
|
|
|
|
{
|
|
|
|
int len = 0;
|
|
|
|
ListCell *tl;
|
|
|
|
|
|
|
|
foreach(tl, targetlist)
|
|
|
|
{
|
Improve castNode notation by introducing list-extraction-specific variants.
This extends the castNode() notation introduced by commit 5bcab1114 to
provide, in one step, extraction of a list cell's pointer and coercion to
a concrete node type. For example, "lfirst_node(Foo, lc)" is the same
as "castNode(Foo, lfirst(lc))". Almost half of the uses of castNode
that have appeared so far include a list extraction call, so this is
pretty widely useful, and it saves a few more keystrokes compared to the
old way.
As with the previous patch, back-patch the addition of these macros to
pg_list.h, so that the notation will be available when back-patching.
Patch by me, after an idea of Andrew Gierth's.
Discussion: https://postgr.es/m/14197.1491841216@sss.pgh.pa.us
2017-04-10 19:51:29 +02:00
|
|
|
TargetEntry *curTle = lfirst_node(TargetEntry, tl);
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
|
|
|
|
if (!curTle->resjunk)
|
|
|
|
len++;
|
|
|
|
}
|
|
|
|
return len;
|
|
|
|
}
|