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

Hi David,

Thank you for the patch!
I reviewed v1. I confirmed the following, so LGTM.

- With debug_parallel_query = regress, the Storage line, which didn't
appear without the patch, is now shown.
- When run in parallel, the Storage lines for Workers 0 to 3 are shown,
and with parallel_leader_participation = on, the leader's line is
shown as well.

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.

I agree with not backpatching this.

While reviewing, I noticed that ExecEndMemoize() overwrites the worker's
slot with memcpy(), so when the Gather is rescanned, only the stats from
the last execution remain. I plan to post a patch in a separate thread
to accumulate the stats instead.

Regards,
Tatsuya Kawata

On Oct 7, 2026, at 09:11, David Rowley <dgrowleyml@gmail.com> wrote:

(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

I think the patch is quite clean and looks very good.

I have a small concern with the output, though it’s not an issue introduced by this patch.

The output is easily read as “used 2849kB of memory”. When Storage shows “Disk”, it would be read as “used NNNkB of disk space”. However, those two metrics are independent: “Storage: Disk” only means “ever used disk”, and “Maximum Storage” means the peak usage, which may come from memory or disk.

I’m not requesting a change to this output, just sharing my thoughts for your reference.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

On Mon, 12 Oct 2026 at 18:17, Tatsuya Kawata
<kawatatatsuya0913@gmail.com> wrote:

Thank you for the patch!
I reviewed v1. I confirmed the following, so LGTM.

Thanks. I pushed this as two separate patches. The 1st adjusts the
tuplestore API, the 2nd adds the Material related EXPLAIN output.

David