Hi David,
I reviewed v1. It applies cleanly to master (3ff475ac12e), and make
check passes.
> EXPLAIN ANALYZE
> SELECT count(*) FROM (VALUES(10000),(1)) v1(r1)
> LEFT JOIN LATERAL (
> SELECT * FROM generate_series(1, 2) gs0
> LEFT JOIN LATERAL (
> SELECT * FROM generate_series(1, v1.r1) gs1
> FULL JOIN generate_series(1, v1.r1) gs4 ON false
> ) ss on true
> ) q on true;
With your example query, I confirmed that the outer Materialize node
reports the same storage regardless of the order of the VALUES. I also
tried it with work_mem = 64kB, so that the larger rescan spills to disk.
The reported value is again the same regardless of the order, and once
the tuplestore has spilled to disk, it keeps being reported as Disk even
if a later rescan is small. LGTM.
A nit in the commit message: "the repored Material storage" should be
"reported".
> > The misreporting of the storage likely isn't a big deal. I suspect
> > rescans of Material nodes are not massively common, so maybe it's not
> > worth backpatching a fix.
>
> I have no evidence but I feel same as you (rescans of Material nodes
> are not massively common). Probably it's not worth backpatching. If we
> need backpatching, we could do it later.
As for backpatching, I agree with you and Ishii-san.
Table Function Scan has the same problem, since
ExecReScanTableFuncScan() also calls tuplestore_end(), so I've posted a
patch fixing it the same way in a separate thread [1].
Regards,
Tatsuya Kawata
[1]
https://www.postgresql.org/message-id/flat/CAHza6qdXjcqXv2aGU7OCakG0OmEsy9-jfP0Gpe2EL%2Bk-AidOhw%40mail.gmail.com
