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

Commit99c7541

Browse files
committed
Fix performance regression in tuplesort specializations
6974924 added 3 new qsort specialization functions aimed to improve theperformance of sorting many of the common pass-by-value data types whenthey're the leading or only sort key.Unfortunately, that has caused a performance regression when sortingdatasets where many of the values being compared were equal. What washappening here was that we were falling back to the standard sortcomparison function to handle tiebreaks. When the two given Datumscompared equally we would incur both the overhead of an indirect functioncall to the standard comparer to perform the tiebreak and also thestandard comparer function would go and compare the leading key needlesslyall over again.Here improve the situation in the 3 new comparison functions. We nowreturn 0 directly when the two Datums compare equally and we're performinga 1-key sort.Here we don't do anything to help the multi-key sort case where theleading key uses one of the sort specializations functions. On testingthis case, even when the leading key's values are all equal, thereappeared to be no performance regression. Let's leave it up to futurework to optimize that case so that the tiebreak function no longerre-compares the leading key over again.Another possible fix for this would have been to add 3 additional sortspecialization functions to handle single-key sorts for thesepass-by-value types. The reason we didn't do that here is that we maydeem some other sort specialization to be more useful than single-keysorts. It may be impractical to have sort specialization functions forevery single combination of what may be useful and it was already decidedthat further analysis into which ones are the most useful would be delayeduntil the v16 cycle. Let's not let this regression force our hand intotrying to make that decision for v15.Author: David RowleyReviewed-by: John NaylorDiscussion:https://postgr.es/m/CA+hUKGJRbzaAOUtBUcjF5hLtaSHnJUqXmtiaLEoi53zeWSizeA@mail.gmail.com
1 parent92e7a53 commit99c7541

File tree

1 file changed

+28
-1
lines changed

1 file changed

+28
-1
lines changed

‎src/backend/utils/sort/tuplesort.c

Lines changed: 28 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -436,7 +436,11 @@ struct Tuplesortstate
436436

437437
/*
438438
* This variable is shared by the single-key MinimalTuple case and the
439-
* Datum case (which both use qsort_ssup()). Otherwise it's NULL.
439+
* Datum case (which both use qsort_ssup()). Otherwise, it's NULL. The
440+
* presence of a value in this field is also checked by various sort
441+
* specialization functions as an optimization when comparing the leading
442+
* key in a tiebreak situation to determine if there are any subsequent
443+
* keys to sort on.
440444
*/
441445
SortSupportonlyKey;
442446

@@ -701,6 +705,13 @@ qsort_tuple_unsigned_compare(SortTuple *a, SortTuple *b, Tuplesortstate *state)
701705
if (compare!=0)
702706
returncompare;
703707

708+
/*
709+
* No need to waste effort calling the tiebreak function when there are
710+
* no other keys to sort on.
711+
*/
712+
if (state->onlyKey!=NULL)
713+
return0;
714+
704715
returnstate->comparetup(a,b,state);
705716
}
706717

@@ -713,9 +724,17 @@ qsort_tuple_signed_compare(SortTuple *a, SortTuple *b, Tuplesortstate *state)
713724
compare=ApplySignedSortComparator(a->datum1,a->isnull1,
714725
b->datum1,b->isnull1,
715726
&state->sortKeys[0]);
727+
716728
if (compare!=0)
717729
returncompare;
718730

731+
/*
732+
* No need to waste effort calling the tiebreak function when there are
733+
* no other keys to sort on.
734+
*/
735+
if (state->onlyKey!=NULL)
736+
return0;
737+
719738
returnstate->comparetup(a,b,state);
720739
}
721740

@@ -728,9 +747,17 @@ qsort_tuple_int32_compare(SortTuple *a, SortTuple *b, Tuplesortstate *state)
728747
compare=ApplyInt32SortComparator(a->datum1,a->isnull1,
729748
b->datum1,b->isnull1,
730749
&state->sortKeys[0]);
750+
731751
if (compare!=0)
732752
returncompare;
733753

754+
/*
755+
* No need to waste effort calling the tiebreak function when there are
756+
* no other keys to sort on.
757+
*/
758+
if (state->onlyKey!=NULL)
759+
return0;
760+
734761
returnstate->comparetup(a,b,state);
735762
}
736763

0 commit comments

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