On 4 May 2016 at 02:10, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
> There are probably a few reasonably simple things we could do - e.g. ignore
> foreign keys with just a single column, as the primary goal of the patch is
> improving estimates with multi-column foreign keys. I believe that covers a
> vast majority of foreign keys in the wild.
>
> If that's deemed insufficient, we'll have to resort to a more complex
> improvement, perhaps something akin to the cache proposed in in the unijoin
> patch. But if that's required, that's 9.7 material.
I had thought that if we had a hashtable of rel OIDs which belong to
relations with has_eclass_joins == true, then we could just skip
foreign keys where the confrelid is not in the hashtable. Perhaps that
could be optimised a bit more and we could have something akin to what
predOK is for IndexOptInfo in ForeignKeyOptInfo which just gets set to
true if the relation referenced by the foreign key is in the
simple_rel_array. It's quite likely that if many foreign keys were
used, then the query would have a great number of joins, and planning
would be slow anyway.
-- David Rowley http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services