From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Foreign join pushdown vs EvalPlanQual |
Date: | 2015-12-09 08:22:38 |
Message-ID: | 5667E4CE.3070807@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015/12/09 13:26, Kouhei Kaigai wrote:
>> On Tue, Dec 8, 2015 at 10:00 PM, Etsuro Fujita
>> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2015-12-09 08:33:06 | Re: Making tab-complete.c easier to maintain |
Previous Message | Tom Lane | 2015-12-09 07:54:27 | Re: Include ppc64le build type for back branches |