WorkTable Scan
Appears in EXPLAIN asWorkTable Scan
Reads the working set of the current recursion step.
What it is
A WorkTable Scan reads the intermediate working table that a Recursive Union fills on each iteration — the rows produced by the previous step that the recursive term builds on.
When the planner picks it
Only inside a WITH RECURSIVE plan, beneath the Recursive Union.
Is it good or bad?
Expected for recursion. If iterations grow unexpectedly, check for cycles (consider UNION instead of UNION ALL, or a cycle/depth guard).
In depth
Reading the previous step
A WorkTable Scan reads the intermediate working table that a
Recursive Union fills on each iteration of a WITH RECURSIVE query. Each
step of the recursion produces rows; those rows become the input the next
iteration scans via this node.
You'll only see WorkTable Scan inside the recursive term of a recursive CTE,
beneath a Recursive Union.
What there is to tune
Not much directly. There is no index on the working table — it's an ephemeral in-memory tuplestore (with disk spill if it grows). What matters is what the recursive term does on each pass:
- Make the recursive step's filtering tight, so iterations don't explode.
- Add a depth or cycle guard if traversing a graph, as covered on the Recursive Union page.
- For wide traversals, materializing intermediate steps into indexed temp tables outside the CTE is sometimes the path forward.
If you see WorkTable Scan with surprising row counts, look at the upstream join condition: an unintended Cartesian step inside the recursion is the classic way recursive CTEs blow up.