| From: | Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com> |
|---|---|
| To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |
| Date: | 2015-05-15 07:19:26 |
| Message-ID: | CAEZqfEcL6yrbqP9Bzg9JE=Ta39-u3r_h=9p2HjxCuMvy8=-Z1Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2015-05-15 8:43 GMT+09:00 Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> Regarding of FDW, as Hanada-san mentioned, I'm uncertain whether
> similar feature is also needed because its join-pushdown feature
> scan on the result-set of remotely joined relations, thus no need
> to have local child Path nodes.
> So, I put this custom_children list on CustomXXXX structure only.
AFAIS most of FDWs won't need child paths to process their external data.
The most possible idea is that a FDW uses output of ForeignScan plan
node which is handled by the FDW, but such work should be done by
another CSP (or at least via CSP I/F).
--
Shigeru HANADA
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2015-05-15 08:31:35 | Re: KNN-GiST with recheck |
| Previous Message | Etsuro Fujita | 2015-05-15 07:15:34 | Minor improvements to alter_foreign_table.sgml |