Re: Foreign join pushdown vs EvalPlanQual

> >> On 2015/10/15 11:36, Kouhei Kaigai wrote:
> >>> In case of scanrelid==0, expectation to ForeignScan/CustomScan is to
> >>> behave as if local join exists here. It requires ForeignScan to generate
> >>> joined-tuple as a result of remote join, that may contains multiple junk
> >>> TLEs to carry whole-var references of base foreign tables.
> >>> According to the criteria, the desirable behavior is clear as below:
> >>>
> >>> 1. FDW/CSP picks up base relation's tuple from the EPQ slots.
> >>> It shall be setup by whole-row reference if earlier row-lock semantics,
> >>> or by RefetchForeignRow if later row-lock semantics.
> >>>
> >>> 2. Fill up ss_ScanTupleSlot according to the xxx_scan_tlist.
> >>> We may be able to provide a common support function here, because this
> >>> list keeps relation between a particular attribute of the joined-tuple
> >>> and its source column.
> >>>
> >>> 3. Apply join-clause and base-restrict that were pushed down.
> >>> setrefs.c initializes expressions kept in fdw_exprs/custom_exprs to run
> >>> on the ss_ScanTupleSlot. It is the easiest way to check here.
> >>>
> >>> 4. If joined-tuple is still visible after the step 3, FDW/CSP returns
> >>> joined-tuple. Elsewhere, returns an empty slot.
> >>>
> >>> It is entirely compatible behavior even if local join is located on
> >>> the point of ForeignScan/CustomScan with scanrelid==0.
> >>>
> >>> Even if remote join is parametalized by other relation, we can simply
> >>> use param-info delivered from the corresponding outer scan at the step-3.
> >>> EState should have the parameters already updated, FDW driver needs to
> >>> care about nothing.
> >>>
> >>> It is quite less invasive approach towards the existing EPQ recheck
> >>> mechanism.
>
> I wrote:
> >> I see. That's an idea, but I guess that step 2 and 3 would need to add
> >> a lot of code to the core. Why don't you use a local join execution
> >> plan that we discussed? I think that that would make the series of
> >> processing much simpler. I'm now revising the patch that I created for
> >> that. If it's okay, I'd like to propose an updated version of the patch
> >> in a few days.
>
> On 2015/10/15 20:19, Kouhei Kaigai wrote:
> > I have to introduce why above idea is simpler and suitable for v9.5
> > timeline.
> > As I've consistently proposed for this two months, the step-2 and 3
> > are assumed to be handled in the callback routine to be kicked from
> > ForeignRecheck().
>
> Honestly, I still don't think I would see the much value in doing so.
> As Robert mentioned in [1], I think that if we're inside EPQ,
> pushed-down quals and/or pushed-down joins should be locally rechecked
> in the same way as other cases such as IndexRecheck. So, I'll propose
> the updated version of the patch.
>
You have never answered my question for two months.

I never deny to execute the pushed-down qualifiers locally.
It is likely the best tactics in most cases.
But, why you try to enforce all the people a particular manner?

Here are various kind of FDW drivers. How do you guarantee it is
the best solution for all the people? It is basically impossible.
(Please google "Probatio diabolica")

You try to add two special purpose fields in ForeignScan;
fdw_recheck_plan and fdw_recheck_quals.
It requires FDW drivers to have pushed-down qualifier in a particular
data format, and also requires FDW drivers to process EPQ recheck by
alternative local plan, even if a part of FDW drivers can process
these jobs by its own implementation better.

I've repeatedly pointed out this issue, but never get reasonable
answer from you.

Again, I also admit alternative plan may be reasonable tactics for
most of FDW drivers. However, only FDW author can "decide" it is
the best tactics to handle the task for their module, not us.

I don't think it is a good interface design to enforce people to
follow a particular implementation manner. It should be discretion
of the extension.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>