This attempts to be as simple as it gets while reducing function call
depth, and should be viewed as a proof of concept. It is also untested
as of now, but will try to do that and report back.
I'm hoping I followed the rabbit hole correctly and are correctly
comparing the right pointers to each other in order to short circuit the
case where we are using the int4 comparison operator.
Peter, if you want to compare stock vs. your patch vs. this patch, we might
be able to get some sort of read on where the maintainablity vs. performance
curve lies. Note that this version should still allow sorting of anything,
and simply shifts gears for int4 tuples...
---src/backend/utils/sort/tuplesort.c | 23 +++++++++++++++++++++--1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c
index 3505236..ddd5ced 100644
--- a/src/backend/utils/sort/tuplesort.c
+++ b/src/backend/utils/sort/tuplesort.c
@@ -2652,6 +2652,22 @@ myFunctionCall2Coll(FmgrInfo *flinfo, Oid collation, Datum arg1, Datum arg2) return result;}
+static inline
+int int4cmp(Datum first, Datum second)
+{
+ int32 a = DatumGetInt32(first);
+ int32 b = DatumGetInt32(second);
+
+ if (a > b)
+ return 1;
+ else if (a == b)
+ return 0;
+ else
+ return -1;
+}
+
+extern Datum btint4cmp(PG_FUNCTION_ARGS);
+/* * Apply a sort function (by now converted to fmgr lookup form) * and return a 3-way comparison result. This takes
careof handling
@@ -2683,8 +2699,11 @@ inlineApplySortFunction(FmgrInfo *sortFunction, int sk_flags, Oid collation, } else {
- compare = DatumGetInt32(myFunctionCall2Coll(sortFunction, collation,
- datum1, datum2));
+ if (sortFunction->fn_addr == btint4cmp)
+ compare = int4cmp(datum1, datum2);
+ else
+ compare = DatumGetInt32(myFunctionCall2Coll(sortFunction, collation,
+ datum1, datum2)); if (sk_flags & SK_BT_DESC)
compare= -compare;
--
1.7.6.3