> On Tue, Dec 8, 2015 at 10:00 PM, Etsuro Fujita
> <fujita.ets...@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.

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 <kai...@ak.jp.nec.com>

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to