forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commita5fc464
committed
Avoid making commutatively-duplicate clauses in EquivalenceClasses.
When we decide we need to make a derived clause equating a.x andb.y, we already will re-use a previously-made clause "a.x = b.y".But we might instead have "b.y = a.x", which is perfectly usablebecause equivclass.c has never promised anything about theoperand order in clauses it builds. Saving construction of anew RestrictInfo doesn't matter all that much in itself --- butbecause we cache selectivity estimates and so on per-RestrictInfo,there's a possibility of saving a fair amount of duplicativeeffort downstream.Hence, check for commutative matches as well as direct ones whenseeing if we have a pre-existing clause. This changes the visibleclause order in several regression test cases, but they're allclearly-insignificant changes.Checking for the reverse operand order is simple enough, butif we wanted to check for operator OID match we'd need to callget_commutator here, which is not so cheap. I concluded thatwe don't really need the operator check anyway, so I justremoved it. It's unlikely that an opfamily contains more thanone applicable operator for a given pair of operand datatypes;and if it does they had better give the same answers, so thereseems little need to insist that we use exactly the oneselect_equality_operator chose.Using the current core regression suite as a test case, I seethis change reducing the number of new join clauses built bycreate_join_clause from 9673 to 5142 (out of 26652 calls).So not quite 50% savings, but pretty close to it.Discussion:https://postgr.es/m/78062.1666735746@sss.pgh.pa.us1 parent4ab8c81 commita5fc464
File tree
5 files changed
+59
-47
lines changed- contrib/postgres_fdw/expected
- src
- backend/optimizer/path
- test/regress/expected
5 files changed
+59
-47
lines changed0 commit comments
Comments
(0)