| From: | solaimurugan vellaipandiyan <drsolaimurugan(dot)v(at)gmail(dot)com> |
|---|---|
| To: | Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, g(dot)kashkin(at)postgrespro(dot)ru, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Function scan FDW pushdown |
| Date: | 2026-05-08 05:17:20 |
| Message-ID: | CAHEL7KQU_=iKQU3dGMV+6vOBWkh=i5g7speEU=VVziRu=3v1Tw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I tested the v3 patch on current master using a postgres_fdw loopback setup.
The patch mostly applied cleanly for me, with only a small manual
conflict resolution needed in postgres_fdw.c (missing
optimizer/clauses.h include). PostgreSQL built and started
successfully after that.
For testing, I used queries involving generate_series() together with
a foreign table, for example:
SELECT *
FROM ft
JOIN generate_series(1,3) g
ON ft.id = g;
I also tried:
1. implicit join syntax
2. LATERAL usage
3. disabling hashjoin/mergejoin to force different join paths
In all cases, the plans still showed a local Function Scan and local
join execution. The Remote SQL remained:
SELECT id FROM public.localtab
So I wasn't able to observe function scan pushdown with these testcases.
Maybe I'm missing a query shape or planner condition required to
trigger the new functionality. It would help to know which cases are
currently expected to be pushed down.
Regards,
Solaimurugan V
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-05-08 05:53:50 | Re: Include schema-qualified names in publication error messages. |
| Previous Message | Chao Li | 2026-05-08 05:09:38 | Re: Call EndCopyFrom() after initial table sync in logical replication |