> 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. > 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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
