Stephen Frost <sfr...@snowman.net> writes: > I'm all for improving performance of postgres_fdw and would like to see > us support sending queries off to be worked asyncronously, but starting > execution on the remote server during ExecInitNode is against the > documentated FDW API spec. I discussed exactly this issue over a year > ago here:
> http://www.postgresql.org/message-id/20131104032604.gb2...@tamriel.snowman.net > Sadly, there weren't any direct responses to that email, but I do recall > having a discussion on another thread (or in person?) with Tom where we > ended up agreeing that we can't simply remove that requirement from the > docs or the API. Yeah. There are at least a couple of reasons why not: * ExecInitNode only creates the runtime data structures, it should not begin execution. It's possible for example that the scan will never be iterated at all; say it's on the inside of a nestloop and the outer relation turns out to be empty. It's not apparent why starting the remote query a few microseconds sooner is worth the risk of demanding useless computation. * If the scan is parameterized (again, it's on the inside of a nestloop, and the outer relation is supplying join key values), those parameter values are simply not available at ExecInitNode time. Also, so far as a quick review of the actual patch goes, I would really like to see this lose the "PFC" wrapper layer, which accounts for 95% of the code churn in the patch and doesn't seem to add any actual value. What it does add is unchecked malloc failure conditions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
