| From: | solaimurugan vellaipandiyan <drsolaimurugan(dot)v(at)gmail(dot)com> |
|---|---|
| To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Cc: | Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>, Á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-11 06:01:04 |
| Message-ID: | CAHEL7KQQkWmt7rg8-dF=wgUJzjcAqqOqKg+xafiCZ2Uy0kP=4g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Thanks for the detailed explanation and the example queries. That
helped me better understand the costing behavior behind the pushdown
decisions.
I tested the new v4 patch on current master using a postgres_fdw
loopback setup with local table t1 and foreign table ft1.
Here’s what I observed:
- Before ANALYZE, the planner chose a local Hash Join with separate
Foreign Scan and Function Scan nodes.
- After running ANALYZE on the empty table, it still preferred local
execution, which makes sense based on the costing explanation.
- I then inserted 1000 rows into t1, ran ANALYZE again, and repeated the test.
Even after that, I still got a local Hash Join plan like:
Hash Join
- Foreign Scan on ft1
- Function Scan on generate_series
I wasn’t able to observe the pushed-down Foreign Scan plan shown in
the example from the thread.
The patch itself applied and built successfully on my side, so this
may just be due to planner cost differences or environment-specific
behavior on current master.
Regards,
Solaimurugan V
| From | Date | Subject | |
|---|---|---|---|
| Next Message | JoongHyuk Shin | 2026-05-11 06:01:56 | Re: [PATCH] Don't call ereport(ERROR) from recovery target GUC assign hooks |
| Previous Message | Shlok Kyal | 2026-05-11 05:50:53 | Re: Support EXCEPT for ALL SEQUENCES publications |