On Mon, Nov 30, 2015 at 2:43 PM, Tom Lane <tgl@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