diff options
author | John Naylor <john.naylor@postgresql.org> | 2022-04-02 15:22:25 +0700 |
---|---|---|
committer | John Naylor <john.naylor@postgresql.org> | 2022-04-02 15:22:25 +0700 |
commit | 6974924347c908335607a4a2f252213d58e21b7c (patch) | |
tree | aa8d5fa5f4aba89f846957410dc0176556180397 /src/backend/utils/adt/uuid.c | |
parent | db086de5abe5d87b07cddd030092b1f81f99c5ea (diff) | |
download | postgresql-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.c | 25 |
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); |