On 2015/12/09 13:26, Kouhei Kaigai wrote:
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.
Sorry, my explanation might be not enough, but I'm not saying to hide
the subplan. I think it would be better to show the subplan somewhere
in the EXPLAIN outout, but I'm not sure that it's a good idea to show
that in the current form. We have two plan trees; one for normal query
execution and another for EvalPlanQual testing. I think it'd be better
to show the EXPLAIN output the way that allows users to easily identify
each of the plan trees.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
