From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | 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-10-19 07:51:59 |
Message-ID: | 5624A11F.4060501@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015/10/17 9:58, Robert Haas wrote:
> But with Etsuro Fujita's patch, and I think what you have proposed has
> been similar, how are you going to do it? The proposal is to call the
> recheck method and hope for the best, but what is the recheck method
> going to do? Where is it going to get the previously-returned tuple?
As I explained in a previous email, just returning the
previously-returned tuple is not good enough.
> How will it know if it has already returned it during the lifetime of
> this EPQ check? Offhand, it looks to me like, at least in some
> circumstances, you're probably going to return whatever tuple you
> returned most recently (which has a good chance of being the right
> one, but not necessarily) over and over again. That's not going to
> fly.
No. Since the local join execution plan is created so that the scan
slot for each foreign table involved in the pushed-down join looks at
its EPQ slot, I think the plan can return at most one tuple.
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-10-19 07:52:28 | plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types |
Previous Message | Kouhei Kaigai | 2015-10-19 07:48:13 | Re: Foreign join pushdown vs EvalPlanQual |