Simon Riggs <si...@2ndquadrant.com> writes: > So a simple change is to make RelationGetFKeyList() only retrieve FKs with > nKeys>1. Rename to RelationGetMultiColumnFKeyList(). That greatly reduces > the scope for increased planning time.
FWIW, I don't particularly agree with that. It makes the relcache's fkey storage extremely specific to this one use-case, a decision I expect we'd regret later. And the planner needs to filter the fkey list anyway, because it only wants fkeys that link to tables that are also in the current query. Thus, my recommendation was that we should allow RelationGetFKeyList to return a pointer directly to the cached info list and require the planner to immediately copy (only) the entries that it needs for the current query. Another point here is that I'm now unconvinced that restricting the logic to consider only multi-column fkeys is really what we want. It looks to me like the code can also improve estimates in the case where there are multiple single-column FKs linking to the same target relation. That might not be too common for two-table queries, but I bet it happens a lot in three-or-more-table queries. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers