Re: New design for FK-based join selectivity estimation

Simon Riggs <simon(at)2ndquadrant(dot)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