Store tuples for EvalPlanQual in slots, rather than as HeapTuples.
For the upcoming pluggable table access methods it's quite
inconvenient to store tuples as HeapTuples, as that'd require
converting tuples from a their native format into HeapTuples. Instead
use slots to manage epq tuples.
To fit into that scheme, change the foreign data wrapper callback
RefetchForeignRow, to store the tuple in a slot. Insist on using the
caller provided slot, so it conveniently can be stored in the
corresponding EPQ slot. As there is no in core user of
RefetchForeignRow, that change was done blindly, but we plan to test
that soon.
To avoid duplicating that work for row locks, move row locks to just
directly use the EPQ slots - it previously temporarily stored tuples
in LockRowsState.lr_curtuples, but that doesn't seem beneficial, given
we'd possibly end up with a significant number of additional slots.
The behaviour of es_epqTupleSet[rti -1] is now checked by
es_epqTupleSlot[rti -1] != NULL, as that is distinguishable from a
slot containing an empty tuple.
Author: Andres Freund, Haribabu Kommi, Ashutosh Bapat
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/ad0bda5d24ea2bcc72b5e50020e3c79bab10836b
Modified Files
--------------
doc/src/sgml/fdwhandler.sgml | 24 ++--
src/backend/executor/execMain.c | 183 +++++++++++++------------------
src/backend/executor/execScan.c | 16 ++-
src/backend/executor/execTuples.c | 26 +++++
src/backend/executor/execUtils.c | 3 +-
src/backend/executor/nodeIndexonlyscan.c | 8 +-
src/backend/executor/nodeIndexscan.c | 8 +-
src/backend/executor/nodeLockRows.c | 92 ++++++----------
src/backend/executor/nodeModifyTable.c | 2 +-
src/include/executor/executor.h | 10 +-
src/include/executor/tuptable.h | 1 +
src/include/foreign/fdwapi.h | 9 +-
src/include/nodes/execnodes.h | 18 ++-
13 files changed, 188 insertions(+), 212 deletions(-)