Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)

On Wed, Sep 9, 2015 at 2:30 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
>> But that path might have already been discarded on the basis of cost.
>> I think Tom's idea is better: let the FDW consult some state cached
>> for this purpose in the RelOptInfo.
>
> Do you have an idea of what information would be collected into the state
> and how the FDW would derive parameterizations to consider producing
> pushed-down joins with from that information?  What I'm concerned about that
> is to reduce the number of parameterizations to consider, to reduce overhead
> in costing the corresponding queries.  I'm missing something, though.

I think the thing we'd want to store in the state would be enough
information to reconstruct a valid join nest.  For example, the
reloptinfo for (A B) might note that A needs to be left-joined to B.
When we go to construct paths for (A B C), and there is no
SpecialJoinInfo that mentions C, we know that we can construct (A LJ
B) IJ C rather than (A IJ B) IJ C.  If any paths survived, we could
find a way to pull that information out of the path, but pulling it
out of the RelOptInfo should always work.

I am not sure what to do about parameterizations.  That's one of my
remaining concerns about moving the hook.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company