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
