On 2015/12/09 2:56, Robert Haas wrote:
On Thu, Dec 3, 2015 at 9:51 PM, Noah Misch <n...@leadboat.com> wrote:
On Tue, Dec 01, 2015 at 11:05:47AM -0500, Robert Haas wrote:
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?
Yes. If 9.5 added a bad interface, better to fix the interface even now than
to live with the bad one.
OK, I've pushed the latest patch for that issue to master and 9.5.
I'm not completely positive we've killed this problem dead, but I hope
so.
Thank you for committing the patch!
Sorry, I overlooked a typo in docs: s/more that one/more than one/
Please find attached a patch.
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml
index 0090e24..dc2d890 100644
--- a/doc/src/sgml/fdwhandler.sgml
+++ b/doc/src/sgml/fdwhandler.sgml
@@ -793,7 +793,7 @@ RecheckForeignScan (ForeignScanState *node, TupleTableSlot *slot);
<literal>ForeignScan</>. When a recheck is required, this subplan
can be executed and the resulting tuple can be stored in the slot.
This plan need not be efficient since no base table will return more
- that one row; for example, it may implement all joins as nested loops.
+ than one row; for example, it may implement all joins as nested loops.
</para>
</sect2>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
