pgconfigurator
pgconfigurator

Named Tuplestore Scan

Appears in EXPLAIN asNamed Tuplestore Scan

Reads trigger transition tables (OLD/NEW row sets).

What it is

A Named Tuplestore Scan reads a named tuplestore — most commonly the OLD TABLE / NEW TABLE transition relations available to AFTER statement-level triggers.

When the planner picks it

Inside trigger functions that reference transition tables.

Is it good or bad?

Normal within trigger logic. Very large statements create large transition tables; keep that in mind for bulk DML with statement triggers.

In depth

Where trigger transition tables live

A Named Tuplestore Scan reads a named in-memory (or temp-spilled) tuplestore. The most common use is trigger transition tables — the OLD TABLE / NEW TABLE relations declared on AFTER statement-level triggers:

CREATE TRIGGER audit_orders
AFTER UPDATE ON orders
REFERENCING OLD TABLE AS old_orders NEW TABLE AS new_orders
FOR EACH STATEMENT
EXECUTE FUNCTION audit_changes();

Inside audit_changes() you can run SELECT * FROM old_orders (or new_orders). The plan inside the function shows Named Tuplestore Scan on old_orders reading those rows.

Cost and limits

The tuplestore lives for the duration of the triggering statement. Reads are cheap and ordered as inserted. There are no indexes on it; if your trigger needs to look rows up by key, do the work yourself (e.g. join against a mapping table, or process the tuplestore in one pass).

For very large transition tables, the tuplestore can spill to a temp file — the same work_mem-like behavior as Sort/Hash. Statement triggers on bulk DML are the case to watch.

See also