| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Material node doesn't show "Maximum Storage" for parallel workers |
| Date: | 2026-10-12 08:10:24 |
| Message-ID: | 18520513-6A3D-4A44-A68F-A10470352078@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Oct 7, 2026, at 09:11, David Rowley <dgrowleyml(at)gmail(dot)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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nitin Jadhav | 2026-10-12 08:13:03 | Re: Reporting WAL replay progress during pre-consistency standby reovery |
| Previous Message | Johannes Edmeier | 2026-10-12 07:53:19 | Re: Detoast a column once per row instead of once per reference |