Material node doesn't show "Maximum Storage" for parallel workers

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Material node doesn't show "Maximum Storage" for parallel workers
Date: 2026-10-07 01:11:34
Message-ID: CAApHDvoUWCms-b27MpDKd5_RUFtAnVrxPgN9u3QoQbBihk+S6g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(This addresses a deficiency in Material node's "Maximum Storage"
output, as highlighted in [1], which proposes adding similar telemetry
to FunctionScan)

1eff8279d "Maximum Storage" for Material nodes, but I failed to think
about getting these details from parallel workers. That's probably not
the end of the world, but it does have the effect of the storage
details going missing when using debug_parallel_query = regress;

Here's a test case I borrowed from select_parallel.sql:

explain analyze
select * from tenk1 t1, tenk2 t2 where t1.two > t2.two; -- correctly
shows Maximum Storage

set debug_parallel_query = regress;
explain analyze
select * from tenk1 t1, tenk2 t2 where t1.two > t2.two; -- Maximum
Storage is missing.

The query uses explain without analyze in select_parallel.sql, so we
don't get any variations from buildfarm members running
debug_parallel_query = regress.

The attached patch aims to fix this. It seemed mostly boilerplate
stuff, so I got Claude Code to write it, and it did so by following
what Memoize does. I only manually adjusted the tuplestore_get_stats()
API afterwards to resolve the issue with transferring the pointer to
the string const into shared memory, plus manual review.

You can test the true parallel query output by running the following setup:

set debug_parallel_query = off;
set parallel_setup_cost=0;
set parallel_tuple_cost=0;
set min_parallel_table_scan_size=0;
set max_parallel_workers_per_gather=4;
set parallel_leader_participation = off;
alter table tenk1 set (parallel_workers = 4);
alter table tenk2 set (parallel_workers = 0);

Doing that, running the query outputs:

-> Materialize ...
Buffers: shared hit=1380
Worker 0: Storage: Memory Maximum Storage: 2849kB
Worker 1: Storage: Memory Maximum Storage: 2849kB
Worker 2: Storage: Memory Maximum Storage: 2849kB
Worker 3: Storage: Memory Maximum Storage: 2849kB

1eff8279d was added in v18, and you could argue this patch is a bug
fix for the missing information in debug_parallel_query = regress, but
also a new feature to show Material telemetry for parallel workers.
Per how debug_parallel_query works, it's really the same thing.

I think this should be master-only. No backpatch.

Any disagreements?

David

[1] https://postgr.es/m/CAHza6qcJUOe4DnSYcKU-VX+7Y8JGbXTyuWj53epskGsOcbzeeA@mail.gmail.com

Attachment Content-Type Size
v1-0001-Show-Material-node-Maximum-Storage-for-parallel-w.patch application/octet-stream 18.4 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2026-10-07 01:14:13 Re: [PATCH] Add memory/disk usage for Function Scan nodes in EXPLAIN
Previous Message Masahiko Sawada 2026-10-07 00:53:40 Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers