Fix EquivalenceClass processing for nested append relations.
The original coding of EquivalenceClasses didn't foresee that appendrel child relations might themselves be appendrels; but this is possible for example when a UNION ALL subquery scans a table with inheritance children. The oversight led to failure to optimize ordering-related issues very well for the grandchild tables. After some false starts involving explicitly flattening the appendrel representation, we found that this could be fixed easily by removing a few implicit assumptions about appendrel parent rels not being children themselves. Kyotaro Horiguchi and Tom Lane, reviewed by Noah Misch
Showing
- src/backend/optimizer/path/allpaths.c 16 additions, 4 deletionssrc/backend/optimizer/path/allpaths.c
- src/backend/optimizer/path/equivclass.c 8 additions, 4 deletionssrc/backend/optimizer/path/equivclass.c
- src/backend/optimizer/plan/createplan.c 1 addition, 1 deletionsrc/backend/optimizer/plan/createplan.c
- src/test/regress/expected/union.out 47 additions, 0 deletionssrc/test/regress/expected/union.out
- src/test/regress/sql/union.sql 29 additions, 0 deletionssrc/test/regress/sql/union.sql
Please register or sign in to comment