On 2015/09/11 6:30, Robert Haas wrote:
> 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.
So, information to address the how-to-build-the-query-text
problem would be stored in the state, in other words. Right?
> I am not sure what to do about parameterizations. That's one of my
> remaining concerns about moving the hook.
I think we should also make it clear what to do about sort orderings.
Best regards,
Etsuro Fujita
