On 2015/09/11 6:30, Robert Haas wrote:
On Wed, Sep 9, 2015 at 2:30 AM, Etsuro Fujita
<fujita.ets...@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.
Do you have any plan about the hook?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
