On Mon, 5 Oct 2026 at 00:14, Tatsuya Kawata <kawatatatsuya0913@gmail.com> wrote:
> Roughly, the split is this: since we can't avoid getting a new
> tuplestore back in materialize mode, a way to save the statistics
> before the tuplestore is discarded (1 and 2) is needed anyway for the
> statistics to be correct, so I'd do that first, while 3 is a performance
> optimisation.
>
> What do you think? I've attached 1 and 2 as v2.
I've read through the patch. Here's my review:
1. I'm confused by the following in explain.sql. We don't support
parallel function scans, so the comments and setting of
max_parallel_workers_per_gather seem bogus:
-- Ensure the Function Scan runs in the leader. The storage information is
-- taken from the leader's tuplestore, so a parallel plan would report
-- nothing here.
set max_parallel_workers_per_gather to 0;
2. In the following, 10000 tuples seems a little excessive to spill 64
kilobytes of work_mem. I checked on a 32-bit build without memory
context checking and 2500 row was enough. 2047 was the most I could
get without spilling, so the extra ~450 seems like a good enough
margin.
set work_mem to 64;
select explain_filter('explain (analyze,buffers off,costs off) select
count(*) from generate_series(1,10000) a(n)');
-- Test tuplestore storage usage in Function Scan with ROWS FROM, which uses
-- one tuplestore per function
select explain_filter('explain (analyze,buffers off,costs off) select
count(*) from rows from (generate_series(1,10000),
generate_series(1,10000)) a(n,m)');
You could also move the existing "reset work_mem;" down after your
tests. Your 10-row test won't spill with work_mem set to 64.
David
