Re: [PATCH] Add memory/disk usage for Function Scan nodes in EXPLAIN

From: Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Yash Jadhav <yash(dot)jadhav8008(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add memory/disk usage for Function Scan nodes in EXPLAIN
Date: 2026-10-15 15:00:34
Message-ID: CAHza6qcLhP1K-1mLKnUr-8KmCbBz-cv8kMjdSVCwf16qiq0XFA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi David,

> I don't think reporting the sum of the maximum space used by each
> function is an accurate way to report the storage space used. I
> believe what we should be showing is the "high water mark" of *total
> storage* used per rescan, not the sum of high water marks per
> function. With what you have, we could report a storage amount that
> was never used by the Function Scan at any single moment in time.
>
> To look at it another way: if you have two bank accounts with ¥1000 in
> one and ¥0 in the other. If today you transfer the ¥1000 into the
> account with ¥0, would you report your total net worth as the sum of
> the maximum balance of the accounts on that day? Surely the answer is
> ¥1000 and not ¥2000, as at no point in time in this scenario did you
> have ¥2000.

Thanks for pointing that out! That makes sense. Attached is v5.

v5 now computes the total space used by the tuplestores that exist at
the same time, and reports the maximum of that.

> explain (analyze, costs off, timing off, summary off) select * from
> (values(1),(2000)) v(i), lateral (select * from rows from
> (generate_series(1, v.i), generate_series(2000, v.i, -1)));

Your example query now shows 111kB, which is almost what you expected.

Regards,
Tatsuya Kawata

Attachment Content-Type Size
v5-0001-Add-memory-disk-usage-for-Function-Scan-nodes-in-.patch application/octet-stream 23.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2026-10-15 15:12:29 Re: [PATCH] Halve peak memory allocation for toast_flatten_tuple
Previous Message alvherre@kurilemu.de 2026-10-15 14:41:56 Re: Bug in logical decoding with DDL and subtransactions