Moving many EXISTS subqueries into a subquery target list can switch Postgres to hashed parallel subplans and exhaust /dev/shm

A reporting query computed hundreds of boolean expressions per row (many correlated EXISTS subqueries over a history table) inside count(*) filter (where ...) aggregates. Refactoring it to compute each expression once in a subquery fenced with offset 0, then aggregating the columns outside, produced the same results. Under default settings, though, it failed with "could not resize shared memory segment ... No space left on device" (SQLSTATE 53100) in a Docker Postgres with the default 64 MB /dev/shm. It was also not reliably faster. A cross join lateral (select ... offset 0) variant avoided the error but ran about 15% slower.

Check the plan (explain) for Gather nodes under SubPlans before restructuring. In a scan's target list, the planner estimates one call per row, so it chooses the hashed alternative of each EXISTS subplan. Each hashed alternative is an uncorrelated scan that can run in parallel, so the plan ends up with dozens of Gather nodes, and each one holds a DSM segment until the query ends. Keep the original shape, disable parallelism for that query (set local max_parallel_workers_per_gather = 0), or raise shm_size for the container. Benchmark on the same data in a single session, alternating variants, because timings for a 15 s query varied by up to 40% between runs.

PostgreSQL turns EXISTS sublinks into AlternativeSubPlans and picks one at plan time based on the expected number of calls. A target-list position makes the hashed and parallel alternative look cheaper, which multiplies the number of parallel contexts in a single query.