| From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-11-04 09:59:02 |
| Message-ID: | 5639D6E6.6070102@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015/11/04 17:28, Kouhei Kaigai wrote:
>> I think we need to consider a general solution that can be applied not
>> only to the case where the component tables in a foreign join all use
>> ROW_MARK_COPY but to the case where those tables use different rowmark
>> types such as ROW_MARK_COPY and ROW_MARK_EXCLUSIVE, as I pointed out
>> upthread.
> In mixture case, FDW/CSP can choose local recheck & reconstruction based
> on the EPQ tuples of base relation. Nobody enforce FDW/CSP to return
> a joined tuple always even if author don't want to support the feature.
> Why do you think it is not a generic solution? FDW/CSP driver "can choose"
> the best solution according to its implementation and capability.
It looked to me that you were discussing only the case where component
foreign tables in a foreign join all use ROW_MARK_COPY, so I commented
that. Sorry for my misunderstanding.
Best regards,
Etsuro Fujita
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-11-04 10:33:51 | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby |
| Previous Message | Etsuro Fujita | 2015-11-04 09:50:23 | Re: Foreign join pushdown vs EvalPlanQual |