Thread

Re: [PATCH] Make ReScanForeignScan callback optional for FDWs

Robert Haas <robertmhaas@gmail.com> — 2025-12-18T18:15:13Z

On Wed, Dec 3, 2025 at 3:45 AM Adam Lee <adam8157@gmail.com> wrote:
> Beyond enabling non-rescannable FDWs, this mechanism could also be used
> for performance optimization on other nodes. Some operations can technically
> support rescan but at significant cost (MergeAppend redo all the sorts,
> Aggregation redo all the calculations...). We may could mark such paths as
> non-rescannable in some cases to encourage the planner to materialize results
> instead.

I'm not 100% sure, but my first reaction is to think that adding a
'rescannable' field to the Path struct is a bad idea. In these other
cases that you mention, I think we'd want to consider the cost of
paths with and without a materialize node and pick the cheaper one. We
don't have a terribly robust model for the cost of rescanning things
today, I think, but improving seems like the right way forward, rather
than making a hard decision that a certain node fully support
rescanning or is totally incapable of it.

My suggestion would be to consider just adding another callback to
FdwRoutine, or maybe giving one of the existing planner callbacks the
additional job of deciding whether rescan is allowed. That's a much
smaller design change. Suddenly making rescannability a property of
every Path node of every kind seems like it could have broad-ranging
ripple effects and I find that pretty scary. Just allowing an FDW to
turn it off if it really can't implement that feels like it might be
reasonable.

-- 
Robert Haas
EDB: http://www.enterprisedb.com