Re: SLOPE - Planner optimizations on monotonic expressions.

Thank you for your review Zsolt,

On Fri, Jul 17, 2026 at 10:16 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
wrote:

> - if (enable_slope && index->rel->reloptkind ==
> RELOPT_BASEREL)
> + if (enable_slope)
> {
> ...
> - if (cpathkey)
> - {
> - /*
> ...

Isn't that cpathkey if/else needed in the !enable_slope case?
>

*PENDING*

I thought I was disabling only a piece of code that was added
on commit 0004.

I will have to go through that part with more time.

On commit 0004 with SET enable_slope = on/off I get
Merge Join
Merge Cond: (t.a = u.a)
-> Index Only Scan using t_a_idx on t
-> Index Only Scan using u_a_idx on u

So even though I don't have a solution I acknowledge that my
assumption was wrong.

> I also realized one more timestamp issue: timestamptz -> timestamp /
> date is not monotonic at a DST change:
>

Removed prosupport for timestamptz <-> timestamp.

> > Additionally,
> > 0003 lets the planner ignore NULLS FIRST or NULLS LAST in a pathkey
> > if the target expression is known to be NOT NULL. This change is is
> > independent of SLOPE implementation.
>
> This patch has an issue in the null handling:
>
> CREATE TABLE l (a int); -- one join column can be NULL
> CREATE TABLE r (b int NOT NULL); -- other join column NOT NULL
> CREATE INDEX ON l (a);
> INSERT INTO l VALUES (1), (2), (NULL);
> INSERT INTO r VALUES (1), (2);
>
> SELECT l.a FROM l LEFT JOIN r ON l.a = r.b ORDER BY l.a NULLS FIRST
>

I clearly underestimated this, removed, to try to keep moving
towards committable.

> + <para>
> + <varname>MONOTONICFUNC_INCREASING</varname>: <literal>x1 >
> x2</literal>
> + implies <literal>f(x1) >= f(x2)</literal>
> + </para>
> + </listitem>
> + <listitem>
> + <para>
> + <varname>MONOTONICFUNC_DECREASING</varname>: <literal>x1 >
> x2</literal>
> + implies <literal>f(x1) >= f(x2)</literal>
> + </para>
>
> Decreasing should be <= ?
>

Sorry, that was because the compilation complained about `<` (xml tag
opener),
in an attempt to avoid using xml entities to keep the source readable I
tried to use
`>`. Now using xml entities `&lt;` and `&gt;`, could use `&ge;` instead of
`&gt;=`
and `&le;` instead of `&lt;=`, maybe more stylish, but the `<=` and `>=` is
what the
operator look like in postgres query language. Any preference here?

DECREASING and BOTH duplicated, both seem to be mistakes.
>
Fixed

> CREATE TABLE orders?

Fixed

0001 - 0005 for your review. 0006 can wait.

Kind Regards
Alexandre