| 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
| 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 |