> [!NOTE] Subquery Scan > <table> > <tr> > <td width="25%"><img src="assets/ex_subqueryscan.png"></td> > <td>A wrapper node used when the planner needs to treat a subquery as a standalone relation. It passes the results of the subquery up the execution tree, often used to bridge different scopes of visibility or filtering.</td> > </tr> > </table> > > ```sql > -- OFFSET prevents pull-up; the outer filter requires a Subquery Scan > EXPLAIN (ANALYZE, COSTS, BUFFERS, VERBOSE) > SELECT * > FROM ( > SELECT id FROM animals > OFFSET 0 > ) s > WHERE id <= 5; > ``` > >  > > ```text > Subquery Scan on s (cost=0.00..299.00 rows=5 width=4) (actual time=0.008..0.567 rows=5 loops=1) > Output: s.id > Filter: (s.id <= 5) > Rows Removed by Filter: 9995 > Buffers: shared hit=74 > -> Seq Scan on public.animals (cost=0.00..174.00 rows=10000 width=4) (actual time=0.007..0.352 rows=10000 loops=1) > Output: animals.id > Buffers: shared hit=74 > Planning: > Buffers: shared hit=76 > Planning Time: 0.419 ms > Execution Time: 0.579 ms > ``` > >  > > <table> > <tr> > <td rowspan="2" width="25%"><img src="assets/ex_subplan.svg"></td> > <td><b>Performance</b></td><td>High performance; essentially a pass-through node for subqueries that the optimizer cannot flatten into the outer query.</td> > </tr> > <tr><td><b>Cost</b></td><td>Equivalent to the cost of the child subquery plan.</td></tr> > </table>