On Tue, 2012-11-06 at 08:35 +0000, Simon Riggs wrote:
> Tom is complaining about conflating the two features, which does seem
> unnecessary. But we can still merge code.
That's a good way to put it.
> Providing run-time parameters or table-level options to Foreign Scans
> seems sensible. I can see why you'd want to pass through parameters
> like "work_mem" to the foreign scan and yet not have those as
> permanent table options.
Right, if you want to set the foreign work_mem differently than the
local work_mem.
> (On another thought: why do Foreign Scans get to avoid the
> materialization we hate with SRFs?)
I don't have an authoritative answer for this, but I *think* it's
because you can specify the begin/iterate/end for the FDW, which allows
you to do proper initialization and teardown regardless of whether the
function runs to completion. Also, you can specify the rescan, which
means that it's up to the FDW author to make sure they produce the same
results again (an SRF isn't required to because it can just output the
materialized results again).
There's probably more work to be done here in FDWs for a few remaining
edge cases, like if the results can't be reproduced on the foreign side
(e.g. twitter feed or something) and parameters are changing.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
