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

Commit6b66dba

Browse files
committed
Compare collations before merging UNION operations.
In the dim past we figured it was okay to ignore collationswhen combining UNION set-operation nodes into a single N-wayUNION operation. I believe that was fine at the time, butit stopped being fine when we added nondeterministic collations:the semantics of distinct-ness are affected by those. v17 madeit even less fine by allowing per-child sorting operations tobe merged via MergeAppend, although I think we accidentallyavoided any live bug from that.Add a check that collations match before deciding that twoUNION nodes are equivalent. I also failed to resist thetemptation to comment plan_union_children() a little better.Back-patch to all supported branches (v13 now), since theyall have nondeterministic collations.Discussion:https://postgr.es/m/3605568.1731970579@sss.pgh.pa.us
1 parent4f8df7a commit6b66dba

File tree

1 file changed

+11
-12
lines changed

1 file changed

+11
-12
lines changed

‎src/backend/optimizer/prep/prepunion.c

Lines changed: 11 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -569,9 +569,9 @@ generate_union_paths(SetOperationStmt *op, PlannerInfo *root,
569569

570570
/*
571571
* If any of my children are identical UNION nodes (same op, all-flag, and
572-
* colTypes) then they can be merged into this node so that we generate
573-
* only one Append and unique-ification for the lot. Recurse to find such
574-
* nodes and compute their children's paths.
572+
* colTypes/colCollations) then they can be merged into this node so that
573+
*we generateonly one Append and unique-ification for the lot. Recurse
574+
*to find suchnodes and compute their children's paths.
575575
*/
576576
rellist=plan_union_children(root,op,refnames_tlist,&tlist_list);
577577

@@ -860,17 +860,15 @@ generate_nonunion_paths(SetOperationStmt *op, PlannerInfo *root,
860860
}
861861

862862
/*
863-
* Pull up children of a UNION node that are identically-propertied UNIONs.
863+
* Pull up children of a UNION node that are identically-propertied UNIONs,
864+
* and perform planning of the queries underneath the N-way UNION.
865+
*
866+
* The result is a list of RelOptInfos containing Paths for sub-nodes, with
867+
* one entry for each descendant that is a leaf query or non-identical setop.
868+
* We also return a parallel list of the childrens' targetlists.
864869
*
865870
* NOTE: we can also pull a UNION ALL up into a UNION, since the distinct
866871
* output rows will be lost anyway.
867-
*
868-
* NOTE: currently, we ignore collations while determining if a child has
869-
* the same properties. This is semantically sound only so long as all
870-
* collations have the same notion of equality. It is valid from an
871-
* implementation standpoint because we don't care about the ordering of
872-
* a UNION child's result: UNION ALL results are always unordered, and
873-
* generate_union_paths will force a fresh sort if the top level is a UNION.
874872
*/
875873
staticList*
876874
plan_union_children(PlannerInfo*root,
@@ -896,7 +894,8 @@ plan_union_children(PlannerInfo *root,
896894

897895
if (op->op==top_union->op&&
898896
(op->all==top_union->all||op->all)&&
899-
equal(op->colTypes,top_union->colTypes))
897+
equal(op->colTypes,top_union->colTypes)&&
898+
equal(op->colCollations,top_union->colCollations))
900899
{
901900
/* Same UNION, so fold children into parent */
902901
pending_rels=lcons(op->rarg,pending_rels);

0 commit comments

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