postgres

mirror of https://github.com/postgres/postgres.git synced 2026-10-31 05:54:36 +03:00

Files

David Rowley a7f8cd811d Use tuplestore_clear instead of tuplestore_end in nodeTableFuncscan.c

Clearing the tuplestore rather than ending it avoids the need for
various memory allocations, so is slightly more efficient.  However, the
main reason to do this is to correctly track the maximum storage used by
the Table Function Scan node.  40708acd65 added additional EXPLAIN
output for Table Function Scan nodes and that output does claim to be
showing "Maximum Storage", which is not true, as the maximums could be
lost after tuplestore_end() is called during a rescan.

This causes misreporting when the final rescan of a Table Function Scan
node uses less storage than some previous rescan.  One example is:

EXPLAIN ANALYZE
SELECT count(*)
FROM (VALUES ((SELECT jsonb_agg(g) FROM generate_series(1, 100000) g)),
             ('[1]'::jsonb)) v(j),
     LATERAL JSON_TABLE(v.j, '$[*]' COLUMNS (x int PATH '$')) jt;

Without this fix, the reported Table Function Scan storage is for the
'[1]'::jsonb case, whereas it should consider how much was used with the
larger document and show the maximum of all rescans.

TableFuncNext() used a NULL tupstore to tell that the rows still had to
be fetched, so add a tupstore_filled flag for that, similar to what
908a96861 did for WindowAgg.

Technically, this issue does exist in v18, but no backpatch as this is a
fairly minor issue which was only noticed during a review of a similar
feature being proposed for Function Scans.

Author: Tatsuya Kawata <kawatatatsuya0913@gmail.com>
Reviewed-by: David Rowley <dgrowleyml@gmail.com>
Discussion: https://postgr.es/m/CAHza6qdXjcqXv2aGU7OCakG0OmEsy9-jfP0Gpe2EL+k-AidOhw@mail.gmail.com

2026-10-05 15:58:13 +13:00