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.