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

From: Yash Jadhav <yash(dot)jadhav8008(at)gmail(dot)com>
To: Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(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-08 19:00:04
Message-ID: CAGsfjr5hzvqFc_N6cGve_wbE-T6kfN5MV6EipcPz1GdjUdD=cg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, I have been studying this thread for the past few days now and
tried to understand the problem,

I was interested in investigating the part of swapping
tuplestore_end() for tuplestore_clear() for function scan.

> When a Function Scan is rescanned with changed parameters, the function
> is called again and the tuplestore is created anew. With
> rsinfo.returnMode == SFRM_ValuePerCall it's created on the executor side
> by ExecMakeTableFunctionResult(), but with SFRM_Materialize it's created
> by the function itself, so the functions would be affected as well.
> Fixing the SFRM_Materialize case would be possible by allowing the
> tuplestore to be passed to the function and calling tuplestore_clear()
> on it, but that would change the SRF calling convention, which looks
> like a fairly large change, extensions included.

For now I understand that for each rerun, a new tuple store would be
obtained along with new stats, and that it would mean changing srf
calling convention in order for the swap to work, but that would mean
a big change. I have also tried to understand the relevant code path.

So I wanted to try if I could find a way to solve this, as a
first-time contributor, I'd appreciate any feedback on whether my
understanding is correct, and whether changing the calling convention
is the only way here.

Thank You. Regards,
Yash Jadhav

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ilia Evdokimov 2026-10-08 19:06:20 Memory leak in statext_ndistinct_build() during ANALYZE
Previous Message Alexander Lakhin 2026-10-08 19:00:00 Re: 041_checkpoint_at_promote.pl might fail due to race condition on child kill