+explain (costs off, verbose)
+select date_trunc('month', ts), count(*)
+from src
+group by 1;
+ QUERY PLAN
+------------------------------------------------------
+ GroupAggregate
+ Output: (date_trunc('month'::text, ts)), count(*)
+ Group Key: date_trunc('month'::text, src.ts)
+ -> Index Only Scan using src_ts_idx on public.src
+ Output: date_trunc('month'::text, ts)
+(5 rows)
That's a good one.
I am glad you noted, I waited for a while for this moment :)
+/* Slope type for representing monotonicity */
+typedef int8 Slope;
+#define SLOPE_ANY 0 /* 0b00 - unknown/either (safe default) */
+#define SLOPE_ASC 1 /* 0b01 - ascending (descending blocked) */
+#define SLOPE_DESC 2 /* 0b10 - descending (ascending blocked) */
+#define SLOPE_CONST 3 /* 0b11 - constant (both blocked) */
The MonotonicFunction enum seems like a good pattern to follow here.
Learning about the existence of that now
typedef enum MonotonicFunction
{
MONOTONICFUNC_NONE = 0,
MONOTONICFUNC_INCREASING = (1 << 0),
MONOTONICFUNC_DECREASING = (1 << 1),
MONOTONICFUNC_BOTH = MONOTONICFUNC_INCREASING | MONOTONICFUNC_DECREASING,
} MonotonicFunction;
So, BOTH means that the function is both increasing and decreasing, thus it is constant.
Simply replacing the SLOPE_* by the corresponding MONOTONICFUNC_* does the job.
But now using an enum we will have 4 bytes per argument.
Nitpick: it's a slope sign (+/-) rather than a slope itself, which to me implies a scalar. I can't think of a good singular word for it, either.
Solved if we use MonotonicFunction I guess. But the word slope isn't always used to refer to derivatives.
And here we are mostly dealing with functions that are constant or discontinuous, i.e. they never have a non-zero real derivative.
+ * If the result is SLOPE_ASC or SLOPE_DESC, *underlying_expr is set to the
+ * by checking the slopes of the function arguments and the expression
+ * passed combined as follows:
"is set to the by" - seems like you left out a word here.
rewording like this
* The contribution of each argument to the final slope of the function
* determined by the slope of the function with respect to an argument
* and the slope of the underlying expression expression passed to it
* as follows:
Patches 0002-0003 would have to get committed at the same time, but I see why you separated them for clarity.
0002 is missing the catversion bump but that's fine at this early stage.
changed catversion this time
So, how would this work with a function like left() with a positive 2nd param (assuming specified collation matches the index)?
That would require a separate prosupport function, it would have to do some extra work, checking if the second argument is a positive constant at planning time.
I'm happy to do that if there is interest, but I would keep after this.
I'm also curious if NULLS FIRST/LAST will throw this off.
All that this will do is, when considering index scans, check if the requested order
matches the index order. And whether we have to do a backwards or forwards scan.
+ if (mono_decreasing)
+ {
+ reverse_sort = !reverse_sort;
+ nulls_first = !nulls_first;
+ }
I think this covers all the cases under consideration.
Added more test cases at the end of 0003.
Is there a specialized nulls first/last sort or does it use a generic sort?
Regards,
Alexandre
