mirror of
https://github.com/postgres/postgres.git
synced 2025-07-09 22:41:56 +03:00
Allow tupleslots to have a fixed tupledesc, use in executor nodes.
The reason for doing so is that it will allow expression evaluation to optimize based on the underlying tupledesc. In particular it will allow to JIT tuple deforming together with the expression itself. For that expression initialization needs to be moved after the relevant slots are initialized - mostly unproblematic, except in the case of nodeWorktablescan.c. After doing so there's no need for ExecAssignResultType() and ExecAssignResultTypeFromTL() anymore, as all former callers have been converted to create a slot with a fixed descriptor. When creating a slot with a fixed descriptor, tts_values/isnull can be allocated together with the main slot, reducing allocation overhead and increasing cache density a bit. Author: Andres Freund Discussion: https://postgr.es/m/20171206093717.vqdxe5icqttpxs3p@alap3.anarazel.de
This commit is contained in:
@ -940,6 +940,26 @@ ExecInitIndexScan(IndexScan *node, EState *estate, int eflags)
|
||||
*/
|
||||
ExecAssignExprContext(estate, &indexstate->ss.ps);
|
||||
|
||||
/*
|
||||
* open the base relation and acquire appropriate lock on it.
|
||||
*/
|
||||
currentRelation = ExecOpenScanRelation(estate, node->scan.scanrelid, eflags);
|
||||
|
||||
indexstate->ss.ss_currentRelation = currentRelation;
|
||||
indexstate->ss.ss_currentScanDesc = NULL; /* no heap scan here */
|
||||
|
||||
/*
|
||||
* get the scan type from the relation descriptor.
|
||||
*/
|
||||
ExecInitScanTupleSlot(estate, &indexstate->ss,
|
||||
RelationGetDescr(currentRelation));
|
||||
|
||||
/*
|
||||
* Initialize result slot, type and projection.
|
||||
*/
|
||||
ExecInitResultTupleSlotTL(estate, &indexstate->ss.ps);
|
||||
ExecAssignScanProjectionInfo(&indexstate->ss);
|
||||
|
||||
/*
|
||||
* initialize child expressions
|
||||
*
|
||||
@ -957,31 +977,6 @@ ExecInitIndexScan(IndexScan *node, EState *estate, int eflags)
|
||||
indexstate->indexorderbyorig =
|
||||
ExecInitExprList(node->indexorderbyorig, (PlanState *) indexstate);
|
||||
|
||||
/*
|
||||
* tuple table initialization
|
||||
*/
|
||||
ExecInitResultTupleSlot(estate, &indexstate->ss.ps);
|
||||
ExecInitScanTupleSlot(estate, &indexstate->ss);
|
||||
|
||||
/*
|
||||
* open the base relation and acquire appropriate lock on it.
|
||||
*/
|
||||
currentRelation = ExecOpenScanRelation(estate, node->scan.scanrelid, eflags);
|
||||
|
||||
indexstate->ss.ss_currentRelation = currentRelation;
|
||||
indexstate->ss.ss_currentScanDesc = NULL; /* no heap scan here */
|
||||
|
||||
/*
|
||||
* get the scan type from the relation descriptor.
|
||||
*/
|
||||
ExecAssignScanType(&indexstate->ss, RelationGetDescr(currentRelation));
|
||||
|
||||
/*
|
||||
* Initialize result tuple type and projection info.
|
||||
*/
|
||||
ExecAssignResultTypeFromTL(&indexstate->ss.ps);
|
||||
ExecAssignScanProjectionInfo(&indexstate->ss);
|
||||
|
||||
/*
|
||||
* If we are just doing EXPLAIN (ie, aren't going to run the plan), stop
|
||||
* here. This allows an index-advisor plugin to EXPLAIN a plan containing
|
||||
|
Reference in New Issue
Block a user