Re: Foreign join pushdown vs EvalPlanQual

Hello, I also uncertain about what exactly is the blocker..

At Fri, 13 Nov 2015 02:31:53 +0000, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote in <9A28C8860F777E439AA12E8AEA7694F80116F7AF(at)BPXM15GP(dot)gisp(dot)nec(dot)co(dot)jp>
> > Sorry, my explanation was not enough. The reason for that is that in
> > the above postgres_fdw case for example, the overhead in sending the
> > query to the remote end and transferring the result to the local end
> > would not be negligible. Yeah, we might be able to apply a special
> > handling for the improved efficiency when using early row locking, but
> > otherwise can we do the same thing?
> >
> It is trade-off. Late locking semantics allows to lock relatively smaller
> number of remote rows, it will take extra latency.
> Also, it became clear we have a challenge to pull a joined tuple at once.

Late row locking anyway needs to send query to the remote side
and needs to generate the joined row in either side of the
connection. Early row locking on FDW don't need that since the
necessary tuples are already in out hand. Is there any
performance issue in this? Unfortunately I've not comprehend what
is the problem:(

Or, Are you Fujita-san thinking about bulk late row locking or
such? If so, it is a matter of future, as update/insert
pushdown, I suppose.

> > I didn't say that my approach is *valuable* either. What I think is, I
> > see zero evidence that there is a good use-case for an FDW to do
> > something other than doing an ExecProcNode in the callback routine, as I
> > said below, so I don't see the need to add such a routine while that
> > would cause maybe not a large, but not a little burden for writing such
> > a routine on FDW authors.
> >
> It is quite natural because we cannot predicate what kind of extension
> is implemented on FDW interface. You might know the initial version of
> PG-Strom is implemented on FDW (about 4 years before...). If I would
> continue to stick FDW, it became a FDW driver with own join engine.
> (cstore_fdw may potentially support own join logic on top of their
> columnar storage for instance?)
>
> From the standpoint of interface design, if we would not admit flexibility
> of implementation unless community don't see a working example, a reasonable
> tactics *for extension author* is to follow the interface restriction even
> if it is not best approach from his standpoint.
> It does not mean the approach by majority is also best for the minority.
> It just requires the minority a compromise.

Or try to open the way to introduce the feature he/she wants. If
workable postgres_fdw with join pushdown based on this API to any
extent be shown here, we can envestigate on the problem
there. But perhaps the deadline is just before us..

> > I did the same thing in an earlier version of the patch I posted.
> > Although I agreed on Robert's comment "The Plan tree and the PlanState
> > tree should be mirror images of each other; breaking that equivalence
> > will cause confusion, at least.", I think that that would make code much
> > simpler, especially the code for setting chgParam for inner/outer
> > subplans.

I see that the Kaigai-san's patch doesn't put different nodes
from paths during plan creation, in other words, it doesn't break
coherence between paths and plans as long as core's point of
view. The Fujita-san's patch mentioned above altered a node in
core's sight. I understand that it is the most significant
difference between them..

> > But one thing I'm concerned about is enable both inner and
> > outer plans, because I think that that would make the planner
> > postprocessing complicated, depending on what the foreign scans do by
> > the inner/outer subplans. Is it worth doing so? Maybe I'm missing
> > something, though.

This is discussion about late row locking? Join pushdown itself
is a kind of complicated process. And since it fools planner in
one aspect, the additional feature would be inevitable to be
complex to some extent. We could discuss on that after some
specific problem comes in out sight.

> If you persuade other person who has different opinion, you need to
> explain why was it complicated, how much complicated and what was
> the solution you tried at that time.
> The "complicated" is a subjectively-based term. At least, we don't
> share your experience, so it is hard to understand the how complexity.

Mee too. It surely might be complicated (though the extent is
mainly in indivisual's mind..) but also I don't see how the
Fujita-san's patch resolves that "problem".

> I guess it is similar to what built-in logic is usually doing, thus,
> it should not be a problem we cannot solve. A utility routine FDW
> driver can call will solve the issue (even if it is not supported
> on v9.5 yet).
>
> > >>> (2) Add a recheck callback.
> > >>>
> > >>> If the foreign data wrapper wants to adopt the solution you're
> > >>> proposing, the recheck callback can call
> > >>> ExecProcNode(outerPlanState(node)). I don't think this should end up
> > >>> being more than a few lines of code, although of course we should
> > >>> verify that.
> >
> > Yeah, I think FDWs would probably need to create a subplan accordingly
> > at planning time, and then initializing/closing the plan at execution
> > time. I think we could facilitate subplan creation by providing helper
> > functions for that, though.
> >
> I can agree with we ought to provide a utility routine to construct
> a local alternative subplan, however, we are in beta2 stage for v9.5.
> So, I'd like to suggest only callback on v9.5 (FDW driver can handle
> its subplan by itself, no need to path the backend), then design the
> utility routine for this.

Support routine itself won't be a blocker since it can be copied
into FDW for the memoent, then we can propose to expose them if
it found to be essential. It would be a problem if some essential
data be found out of reach, but I guess we have all required data
already in hand.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center