Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit477023e

Browse files
committed
Fix some more problems with nested append relations.
As of commita87c729 (which later got backpatched as far as 9.1),we're explicitly supporting the notion that append relations can benested; this can occur when UNION ALL constructs are nested, or whena UNION ALL contains a table with inheritance children.Bug #11457 from Nelson Page, as well as an earlier report from ElvisPranskevichus, showed that there were still nasty bugs associated with suchcases: in particular the EquivalenceClass mechanism could try to generate"join" clauses connecting an appendrel child to some grandparent appendrel,which would result in assertion failures or bogus plans.Upon investigation I concluded that all current callers offind_childrel_appendrelinfo() need to be fixed to explicitly considermultiple levels of parent appendrels. The most complex fix was inprocessing of "broken" EquivalenceClasses, which are ECs for which we havebeen unable to generate all the derived equality clauses we would like tobecause of missing cross-type equality operators in the underlying btreeoperator family. That code path is more or less entirely untested bythe regression tests to date, because no standard opfamilies have suchholes in them. So I wrote a new regression test script to try to exerciseit a bit, which turned out to be quite a worthwhile activity as it exposedexisting bugs in all supported branches.The present patch is essentially the same as far back as 9.2, which iswhere parameterized paths were introduced. In 9.0 and 9.1, we only needto back-patch a small fragment of commit5b7b551, which fixes failure topropagate out the original WHERE clauses when a broken EC contains constantmembers. (The regression test case results show that these older branchesare noticeably stupider than 9.2+ in terms of the quality of the plansgenerated; but we don't really care about plan quality in such cases,only that the plan not be outright wrong. A more invasive fix in theolder branches would not be a good idea anyway from a plan-stabilitystandpoint.)
1 parentd1844c2 commit477023e

File tree

5 files changed

+619
-3
lines changed

5 files changed

+619
-3
lines changed

‎src/backend/optimizer/path/equivclass.c

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -902,7 +902,12 @@ generate_base_implied_equalities_no_const(PlannerInfo *root,
902902
* of the EC back into the main restrictinfo datastructures. Multi-relation
903903
* clauses will be regurgitated later by generate_join_implied_equalities().
904904
* (We do it this way to maintain continuity with the case that ec_broken
905-
* becomes set only after we've gone up a join level or two.)
905+
* becomes set only after we've gone up a join level or two.) However, for
906+
* an EC that contains constants, we can adopt a simpler strategy and just
907+
* throw back all the source RestrictInfos immediately; that works because
908+
* we know that such an EC can't become broken later. (This rule justifies
909+
* ignoring ec_has_const ECs in generate_join_implied_equalities, even when
910+
* they are broken.)
906911
*/
907912
staticvoid
908913
generate_base_implied_equalities_broken(PlannerInfo*root,
@@ -914,7 +919,8 @@ generate_base_implied_equalities_broken(PlannerInfo *root,
914919
{
915920
RestrictInfo*restrictinfo= (RestrictInfo*)lfirst(lc);
916921

917-
if (bms_membership(restrictinfo->required_relids)!=BMS_MULTIPLE)
922+
if (ec->ec_has_const||
923+
bms_membership(restrictinfo->required_relids)!=BMS_MULTIPLE)
918924
distribute_restrictinfo_to_rels(root,restrictinfo);
919925
}
920926
}

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp