| 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 |
| 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 |