aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/uuid.c
diff options
context:
space:
mode:
authorJohn Naylor <john.naylor@postgresql.org>2022-04-02 15:22:25 +0700
committerJohn Naylor <john.naylor@postgresql.org>2022-04-02 15:22:25 +0700
commit6974924347c908335607a4a2f252213d58e21b7c (patch)
treeaa8d5fa5f4aba89f846957410dc0176556180397 /src/backend/utils/adt/uuid.c
parentdb086de5abe5d87b07cddd030092b1f81f99c5ea (diff)
downloadpostgresql-6974924347c908335607a4a2f252213d58e21b7c.tar.gz
postgresql-6974924347c908335607a4a2f252213d58e21b7c.zip
Specialize tuplesort routines for different kinds of abbreviated keys
Previously, the specialized tuplesort routine inlined handling for reverse-sort and NULLs-ordering but called the datum comparator via a pointer in the SortSupport struct parameter. Testing has showed that we can get a useful performance gain by specializing datum comparison for the different representations of abbreviated keys -- signed and unsigned 64-bit integers and signed 32-bit integers. Almost all abbreviatable data types will benefit -- the only exception for now is numeric, since the datum comparison is more complex. The performance gain depends on data type and input distribution, but often falls in the range of 10-20% faster. Thomas Munro Reviewed by Peter Geoghegan, review and performance testing by me Discussion: https://www.postgresql.org/message-id/CA%2BhUKGKKYttZZk-JMRQSVak%3DCXSJ5fiwtirFf%3Dn%3DPAbumvn1Ww%40mail.gmail.com
Diffstat (limited to 'src/backend/utils/adt/uuid.c')
-rw-r--r--src/backend/utils/adt/uuid.c25
1 files changed, 5 insertions, 20 deletions
diff --git a/src/backend/utils/adt/uuid.c b/src/backend/utils/adt/uuid.c
index 9e06d9ba123..a157f864e12 100644
--- a/src/backend/utils/adt/uuid.c
+++ b/src/backend/utils/adt/uuid.c
@@ -34,7 +34,6 @@ typedef struct
static void string_to_uuid(const char *source, pg_uuid_t *uuid);
static int uuid_internal_cmp(const pg_uuid_t *arg1, const pg_uuid_t *arg2);
static int uuid_fast_cmp(Datum x, Datum y, SortSupport ssup);
-static int uuid_cmp_abbrev(Datum x, Datum y, SortSupport ssup);
static bool uuid_abbrev_abort(int memtupcount, SortSupport ssup);
static Datum uuid_abbrev_convert(Datum original, SortSupport ssup);
@@ -255,7 +254,7 @@ uuid_sortsupport(PG_FUNCTION_ARGS)
ssup->ssup_extra = uss;
- ssup->comparator = uuid_cmp_abbrev;
+ ssup->comparator = ssup_datum_unsigned_cmp;
ssup->abbrev_converter = uuid_abbrev_convert;
ssup->abbrev_abort = uuid_abbrev_abort;
ssup->abbrev_full_comparator = uuid_fast_cmp;
@@ -279,20 +278,6 @@ uuid_fast_cmp(Datum x, Datum y, SortSupport ssup)
}
/*
- * Abbreviated key comparison func
- */
-static int
-uuid_cmp_abbrev(Datum x, Datum y, SortSupport ssup)
-{
- if (x > y)
- return 1;
- else if (x == y)
- return 0;
- else
- return -1;
-}
-
-/*
* Callback for estimating effectiveness of abbreviated key optimization.
*
* We pay no attention to the cardinality of the non-abbreviated data, because
@@ -390,10 +375,10 @@ uuid_abbrev_convert(Datum original, SortSupport ssup)
/*
* Byteswap on little-endian machines.
*
- * This is needed so that uuid_cmp_abbrev() (an unsigned integer 3-way
- * comparator) works correctly on all platforms. If we didn't do this,
- * the comparator would have to call memcmp() with a pair of pointers to
- * the first byte of each abbreviated key, which is slower.
+ * This is needed so that ssup_datum_unsigned_cmp() (an unsigned integer
+ * 3-way comparator) works correctly on all platforms. If we didn't do
+ * this, the comparator would have to call memcmp() with a pair of pointers
+ * to the first byte of each abbreviated key, which is slower.
*/
res = DatumBigEndianToNative(res);