| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com> |
| Subject: | Re: Foreign join pushdown vs EvalPlanQual |
| Date: | 2015-12-07 18:06:42 |
| Message-ID: | 11405.1449511602@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I think the core system likely needs visibility into where paths and
> plans are present in node trees, and putting them somewhere inside
> fdw_private would be going in the opposite direction.
Absolutely. You don't really want FDWs having to take responsibility
for setrefs.c processing of their node trees, for example. This is why
e.g. ForeignScan has both fdw_exprs and fdw_private.
I'm not too concerned about whether we have to adjust FDW-related APIs
as we go along. It's been clear from the beginning that we'd have to
do that, and we are nowhere near a point where we should promise that
we're done doing so.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2015-12-07 18:18:21 | Re: Using quicksort for every external sort run |
| Previous Message | Andrew Dunstan | 2015-12-07 17:05:55 | Re: jsonb_delete not documented |