You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Limit the number of rel sets considered in consider_index_join_outer_rels.
In bug #7626, Brian Dunavant exposes a performance problem created bycommit3b8968f: that commit attempted toconsider *all* possible combinations of indexable join clauses, but if saidclauses join to enough different relations, there's an exponential increasein the number of outer-relation sets considered.In Brian's example, all the clauses come from the same equivalence class,which means it's redundant to use more than one of them in an indexscananyway. So we can prevent the problem in this class of cases (which isprobably the majority of real examples) by rejecting combinations thatwould only serve to add a known-redundant clause.But that still leaves us exposed to exponential growth of planning timewhen the query has a lot of non-equivalence join clauses that are usablewith the same index. I chose to prevent such cases by setting an upperlimit on the number of relation sets considered, equal to ten times thenumber of index clauses considered so far. (This sliding limit stillallows new relsets to be added on as we move to additional index columns,which is probably more important than considering even more combinations ofclauses for the previous column.) This should keep the amount of work doneroughly linear rather than exponential in the apparent query complexity.This part of the fix is pretty ad-hoc; but without a clearer idea ofreal-world cases for which this would result in markedly inferior plans,it's hard to see how to do better.