Re: Function scan FDW pushdown

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

In response to

Responses

Browse pgsql-hackers by date

  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