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>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, 花田茂 <shigeru(dot)hanada(at)gmail(dot)com>
Subject: Re: Foreign join pushdown vs EvalPlanQual
Date: 2015-08-26 03:35:32
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi KaiGai-san,

On 2015/08/25 10:18, Kouhei Kaigai wrote:
> How about your opinion towards the solution?

>> Likely, what you need to do are...
>> 1. Save the alternative path on fdw_paths when foreign join push-down.
>> GetForeignJoinPaths() may be called multiple times towards a particular
>> joinrel according to the combination of innerrel/outerrel.
>> RelOptInfo->fdw_private allows to avoid construction of same remote
>> join path multiple times. On the second or later invocation, it may be
>> a good tactics to reference cheapest_startup_path and replace the saved
>> one if later invocation have cheaper one, prior to exit.

I'm not sure that the tactics is a good one. I think you probably
assume that GetForeignJoinPaths executes set_cheapest each time that
gets called, but ISTM that that would be expensive. (That is one of the
reason why I think it would be better to hook that routine in

>> 2. Save the alternative Plan nodes on fdw_plans or lefttree/righttree
>> somewhere you like at the GetForeignPlan()
>> 3. Makes BeginForeignScan() to call ExecInitNode() towards the plan node
>> saved at (2), then save the PlanState on fdw_ps, lefttree/righttree,
>> or somewhere private area if not displayed on EXPLAIN.
>> 4. Implement ForeignRecheck() routine. If scanrelid==0, it kicks the
>> planstate node saved at (3) to generate tuple slot. Then, call the
>> ExecQual() to check qualifiers being pushed down.
>> 5. Makes EndForeignScab() to call ExecEndNode() towards the PlanState
>> saved at (3).

>> I never think above steps are "too" complicated for people who can write
>> FDW drivers. It is what developer usually does.

Sorry, my explanation was not accurate, but the design that you proposed
looks complicated beyond necessity. I think we should add an FDW API
for doing something if FDWs have more knowledge about doing that than
the core, but in your proposal, instead of the core, an FDW has to
eventually do a lot of the core's work: ExecInitNode, ExecProcNode,
ExecQual, ExecEndNode and so on.

Thank you for the comments!

Best regards,
Etsuro Fujita

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2015-08-26 04:49:55 Re: Foreign join pushdown vs EvalPlanQual
Previous Message Joe Conway 2015-08-26 03:32:55 Re: exposing pg_controldata and pg_config as functions