diff options
author | Andres Freund <andres@anarazel.de> | 2019-09-05 13:00:20 -0700 |
---|---|---|
committer | Andres Freund <andres@anarazel.de> | 2019-09-09 05:14:11 -0700 |
commit | 27cc7cd2bc8a5e8efc8279bc5d2a8ae42fd8ad33 (patch) | |
tree | 090b7fb7a079d651ddab923befdcf8755f23e40e /src/backend/executor/nodeIndexscan.c | |
parent | 7e04160390464cd39690d36054e0ac5e4f1bf227 (diff) | |
download | postgresql-27cc7cd2bc8a5e8efc8279bc5d2a8ae42fd8ad33.tar.gz postgresql-27cc7cd2bc8a5e8efc8279bc5d2a8ae42fd8ad33.zip |
Reorder EPQ work, to fix rowmark related bugs and improve efficiency.
In ad0bda5d24ea I changed the EvalPlanQual machinery to store
substitution tuples in slot, instead of using plain HeapTuples. The
main motivation for that was that using HeapTuples will be inefficient
for future tableams. But it turns out that that conversion was buggy
for non-locking rowmarks - the wrong tuple descriptor was used to
create the slot.
As a secondary issue 5db6df0c0 changed ExecLockRows() to begin EPQ
earlier, to allow to fetch the locked rows directly into the EPQ
slots, instead of having to copy tuples around. Unfortunately, as Tom
complained, that forces some expensive initialization to happen
earlier.
As a third issue, the test coverage for EPQ was clearly insufficient.
Fixing the first issue is unfortunately not trivial: Non-locked row
marks were fetched at the start of EPQ, and we don't have the type
information for the rowmarks available at that point. While we could
change that, it's not easy. It might be worthwhile to change that at
some point, but to fix this bug, it seems better to delay fetching
non-locking rowmarks when they're actually needed, rather than
eagerly. They're referenced at most once, and in cases where EPQ
fails, might never be referenced. Fetching them when needed also
increases locality a bit.
To be able to fetch rowmarks during execution, rather than
initialization, we need to be able to access the active EPQState, as
that contains necessary data. To do so move EPQ related data from
EState to EPQState, and, only for EStates creates as part of EPQ,
reference the associated EPQState from EState.
To fix the second issue, change EPQ initialization to allow use of
EvalPlanQualSlot() to be used before EvalPlanQualBegin() (but
obviously still requiring EvalPlanQualInit() to have been done).
As these changes made struct EState harder to understand, e.g. by
adding multiple EStates, significantly reorder the members, and add a
lot more comments.
Also add a few more EPQ tests, including one that fails for the first
issue above. More is needed.
Reported-By: yi huang
Author: Andres Freund
Reviewed-By: Tom Lane
Discussion:
https://postgr.es/m/CAHU7rYZo_C4ULsAx_LAj8az9zqgrD8WDd4hTegDTMM1LMqrBsg@mail.gmail.com
https://postgr.es/m/24530.1562686693@sss.pgh.pa.us
Backpatch: 12-, where the EPQ changes were introduced
Diffstat (limited to 'src/backend/executor/nodeIndexscan.c')
-rw-r--r-- | src/backend/executor/nodeIndexscan.c | 22 |
1 files changed, 13 insertions, 9 deletions
diff --git a/src/backend/executor/nodeIndexscan.c b/src/backend/executor/nodeIndexscan.c index ac7aa81f674..c06d07aa467 100644 --- a/src/backend/executor/nodeIndexscan.c +++ b/src/backend/executor/nodeIndexscan.c @@ -827,25 +827,27 @@ void ExecIndexMarkPos(IndexScanState *node) { EState *estate = node->ss.ps.state; + EPQState *epqstate = estate->es_epq_active; - if (estate->es_epqTupleSlot != NULL) + if (epqstate != NULL) { /* * We are inside an EvalPlanQual recheck. If a test tuple exists for * this relation, then we shouldn't access the index at all. We would * instead need to save, and later restore, the state of the - * es_epqScanDone flag, so that re-fetching the test tuple is - * possible. However, given the assumption that no caller sets a mark - * at the start of the scan, we can only get here with es_epqScanDone + * relsubs_done flag, so that re-fetching the test tuple is possible. + * However, given the assumption that no caller sets a mark at the + * start of the scan, we can only get here with relsubs_done[i] * already set, and so no state need be saved. */ Index scanrelid = ((Scan *) node->ss.ps.plan)->scanrelid; Assert(scanrelid > 0); - if (estate->es_epqTupleSlot[scanrelid - 1] != NULL) + if (epqstate->relsubs_slot[scanrelid - 1] != NULL || + epqstate->relsubs_rowmark[scanrelid - 1] != NULL) { /* Verify the claim above */ - if (!estate->es_epqScanDone[scanrelid - 1]) + if (!epqstate->relsubs_done[scanrelid - 1]) elog(ERROR, "unexpected ExecIndexMarkPos call in EPQ recheck"); return; } @@ -862,17 +864,19 @@ void ExecIndexRestrPos(IndexScanState *node) { EState *estate = node->ss.ps.state; + EPQState *epqstate = estate->es_epq_active; - if (estate->es_epqTupleSlot != NULL) + if (estate->es_epq_active != NULL) { /* See comments in ExecIndexMarkPos */ Index scanrelid = ((Scan *) node->ss.ps.plan)->scanrelid; Assert(scanrelid > 0); - if (estate->es_epqTupleSlot[scanrelid - 1] != NULL) + if (epqstate->relsubs_slot[scanrelid - 1] != NULL || + epqstate->relsubs_rowmark[scanrelid - 1] != NULL) { /* Verify the claim above */ - if (!estate->es_epqScanDone[scanrelid - 1]) + if (!epqstate->relsubs_done[scanrelid - 1]) elog(ERROR, "unexpected ExecIndexRestrPos call in EPQ recheck"); return; } |