On Mon, Nov 30, 2015 at 2:43 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > * Foreign join pushdown vs EvalPlanQual > > Is this fixed by 5fc4c26db? If not, what remains to do?
Unfortunately, no. That commit allows FDWs to do proper EPQ handling for plain table scans, but it proves to be inadequate for EPQ handling for joins. Solving that problem will require another patch, and, modulo a bunch of cosmetic issues, I'm reasonably happy with KaiGai Kohei's latest submission. I'll respond in more detail on that thread, but the question I want to raise here is: do we want to back-patch those changes to 9.5 at this late date? If we don't, then join pushdown won't be usable in 9.5 for queries that have locking clauses; it will crash. However, it may be that nobody's going to try to do that anyway. And if they do, they have the PlannerInfo available when generating paths, so they can just not push down any joins when there are row marks, which doesn't sound like the worst thing that ever happened to anybody. It's also possible that the fix isn't really correct and we won't find that out until after release, at which point it'll be too late to tinker with the API (if it isn't already). On the other hand, what do we get out of shipping an API that we know to be a few bricks short of a load? I think the risk of collateral damage is low. If there's a problem, I expect it to be that the join-pushdown-vs-EPQ problem is still not solved, not that anything else stops working. >From the point of view of existing FDWs, the most noticeable effect of the patch is that you'll have to pass one more NULL argument to functions make_foreignscan(). This will break compiles, but it should be a more trivial repair than what 5fc4c26db demanded. So maybe it's OK. I could go either way on this. What do others think? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
