Result

Description

Evaluates a projection and an optional one-time condition, with or without an input plan.

Core node tag

T_Result

Structured EXPLAIN Node Type

Result

Inputs

Optional child plan

Output

Projected tuples

Executor initializer

ExecInitResult

Memory mechanism

unclassified

EXPLAIN names and attributes

Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.

Text names recorded by this source: Result.

Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node.

Memory and temporary storage

This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.

Parallel execution and instrumentation

The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.

Callbacks in this build: none extracted from this node implementation.

Same-version manual discussion

The rows value is a little tricky because it is not the number of rows processed or scanned by the plan node, but rather the number emitted by the node. This is often less than the number scanned, as a result of filtering by any WHERE -clause conditions that are being applied at the node. Ideally the top-level rows estimate will approximate the number of rows actually returned, updated, or deleted by the query.

Compared to regular sorts, sorting incrementally allows returning tuples before the entire result set has been sorted, which particularly enables optimizations with LIMIT queries. It may also reduce memory usage and the likelihood of spilling sorts to disk, but it comes at the cost of the increased overhead of splitting the result set into multiple sorting batches.

In this plan, we have a nested-loop join node with two table scans as inputs, or children. The indentation of the node summary lines reflects the plan tree structure. The join's first, or “ outer ” , child is a bitmap scan similar to those we saw before. Its cost and row count are the same as we'd get from SELECT ... WHERE unique1 < 10 because we are applying the WHERE clause unique1 < 10 at that node. The t1.unique2 = t2.unique2 clause is not relevant yet, so it doesn't affect the row count of the outer scan. The nested-loop join node will run its second, or “ inner ” child once for each row obtained from the outer child. Column values from the current outer row can be plugged into the inner scan; here, the t1.unique2 value from the outer row is available, so we get a plan and costs similar to what we saw above for a simple SELECT ... WHERE t2.unique2 = constant case. (The estimated cost is actually a bit lower than what was seen above, as a result of caching that's expected to occur during the repeated index scans on t2 .) The costs of the loop node are then set on the basis of the cost of the outer scan, plus one repetition of the inner scan for each outer row (10 * 7.90, here), plus a little CPU time for join processing.

This rather artificial example serves to illustrate a couple of points: values from the outer plan level can be passed down into a subplan (here, t.four is passed down) and the results of the sub-select are available to the outer plan. Those result values are shown by EXPLAIN with notations like ( subplan_name ).col N , which refers to the N 'th output column of the sub- SELECT .

It is possible to check the accuracy of the planner's estimates by using EXPLAIN 's ANALYZE option. With this option, EXPLAIN actually executes the query, and then displays the true row counts and true run time accumulated within each plan node, along with the same estimates that a plain EXPLAIN shows. For example, we might get a result like this:

Because each worker executes the parallel portion of the plan to completion, it is not possible to simply take an ordinary query plan and run it using multiple workers. Each worker would produce a full copy of the output result set, so the query would not run any faster than normal but would produce incorrect results. Instead, the parallel portion of the plan must be what is known internally to the query optimizer as a partial plan ; that is, it must be constructed so that each process that executes the plan will generate only a subset of the output rows in such a way that each required output row is guaranteed to be generated by exactly one of the cooperating processes. Generally, this means that the scan on the driving table of the query must be a parallel-aware scan.

Examples from this manual build

Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.

If, in addition to not referencing any variables of the outer query, the sub- SELECT cannot return more than one row, it may instead be implemented as an initplan :

EXPLAIN VERBOSE SELECT unique1
FROM tenk1 t1 WHERE t1.ten = (SELECT (random() * 10)::integer);

                             QUERY PLAN
--------------------------------------------------------------------
 Seq Scan on public.tenk1 t1  (cost=0.02..470.02 rows=1000 width=4)
   Output: t1.unique1
   Filter: (t1.ten = (InitPlan 1).col1)
   InitPlan 1
     ->  Result  (cost=0.00..0.02 rows=1 width=4)
           Output: ((random() * '10'::double precision))::integer

Executor implementation notes

nodeResult.c support for constant nodes needing special code.

Result nodes are used in queries where no relations are scanned. Examples of such queries are:

(Remember that in an INSERT or UPDATE, we need a plan tree that generates the new rows.)

Result nodes are also used to optimise queries with constant qualifications (ie, quals that do not depend on the scanned data), such as:

At runtime, the Result node evaluates the constant qual once, which is shown by EXPLAIN as a One-Time Filter. If it's false, we can return an empty result set without running the controlled plan at all. If it's true, we run the controlled plan normally and pass back the results.

EXPLAIN identity in core source

case T_Result:
			pname = sname = "Result";
			break;

Related entries

• EXPLAIN
• Using EXPLAIN
• Parallel plans

Documentation and source

• src/backend/commands/explain.c:1379
• src/backend/executor/execProcnode.c:166
• src/backend/executor/nodeResult.c
• src/include/nodes/plannodes.h
• PostgreSQL 18.6 · using-explain
• PostgreSQL 18.6 · using-explain
• PostgreSQL 18.6 · parallel-plans

Compare versions

PostgreSQL 17 → 18: unchanged.

Compares recorded interfaces and attributes. Source fingerprints and build metadata are excluded; an absent sample is not proof of the introduction or removal release.

Related entries

• LimitLimit
• LockRowsLockRows
• ProjectSetProjectSet