pgconfigurator
pgconfigurator

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.

See also