Re: Foreign join pushdown vs EvalPlanQual

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

In response to

Responses

Browse pgsql-hackers by date

  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