On 4 May 2016 at 02:10, Tomas Vondra <tomas.von...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
