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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
