Re: SLOPE - Planner optimizations on monotonic expressions.

>
> +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.

+/* 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.

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.

+ * 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.

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.

So, how would this work with a function like left() with a positive 2nd
param (assuming specified collation matches the index)? I'm also curious if
NULLS FIRST/LAST will throw this off.