↑↓ select ↵ open ⌫ change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

Wiki / Plan Nodes / Scan

Values Scan

ValuesScan

Evaluates and scans a VALUES row list.

Reading PostgreSQL 18.6.

Description

Evaluates and scans a VALUES row list.

Core node tag
T_ValuesScan
Structured EXPLAIN Node Type
Values Scan
Inputs
A list of row expressions
Output
VALUES tuples
Executor initializer
ExecInitValuesScan
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: Values Scan.

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.

Executor implementation notes

nodeValuesscan.c Support routines for scanning Values lists ("VALUES (...), (...), ..." in rangetable).

Always clear the result slot; this is appropriate if we are at the end of the data, and if we're not, we still need it as the first step of the store-virtual-tuple protocol. It seems wise to clear the slot before we reset the context it might have pointers into.

Get rid of any prior cycle's leftovers. We use ReScanExprContext not just ResetExprContext because we want any registered shutdown callbacks to be called.

Unless we already made the expression eval state for this row, build it in the econtext's per-tuple memory. This is a tad unusual, but we want to delete the eval state again when we move to the next row, to avoid growth of memory requirements over a long values list. For rows in which that won't work, we already built the eval state at plan startup.

Pass parent as NULL, not my plan node, because we don't want anything in this transient state linking into permanent state. The only expression type that might wish to do so is a SubPlan, and we already checked that there aren't any.

EXPLAIN identity in core source

case T_ValuesScan:
			pname = sname = "Values Scan";
			break;

EXPLAIN labels in this source build

Text-format labelStructured node identity
Values ScanValues Scan

Related entries

Documentation and source

Source build
Version
18.6
Build
PostgreSQL 18.6 source archive
Source fingerprint
555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f

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

Export JSON · Back to Plan Nodes · Recorded in PostgreSQL 10 through 20; the first sample is not necessarily its introduction.