Re: Foreign join pushdown vs EvalPlanQual

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

In response to

Browse pgsql-hackers by date

  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