> On Tue, Dec 8, 2015 at 10:00 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:
> >> I think the actual regression test outputs are fine, and that your
> >> desire to suppress part of the plan tree from showing up in the
> >> EXPLAIN output is misguided. I like it just the way it is. To
> >> prevent user confusion, I think that when we add support to
> >> postgres_fdw for this we might also want to add some documentation
> >> explaining how to interpret this EXPLAIN output, but I don't think
> >> there's any problem with the output itself.
> >
> > I'm not sure that that's a good idea. one reason for that is I think that
> > that would be more confusing to users when more than two foreign tables are
> > involved in a foreign join as shown in the following example. Note that the
> > outer plans will be shown recursively. Another reason is there is no
> > consistency between the costs of the outer plans and that of the main plan.
>
> I still don't really see a problem here, but, regardless, the solution
> can't be to hide nodes that are in fact present from the user. We can
> talk about making further changes here, but hiding the nodes
> altogether is categorically out in my mind.
>
Fujita-san,
If you really want to hide the alternative sub-plan, you can move the
outer planstate onto somewhere private field on BeginForeignScan,
then kick ExecProcNode() at the ForeignRecheck callback by itself.
Explain walks down the sub-plan if outerPlanState(planstate) is
valid. So, as long as your extension keeps the planstate privately,
it is not visible from the EXPLAIN.
Of course, I don't recommend it.
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>