Re: SLOPE - Planner optimizations on monotonic expressions. - Mailing list pgsql-hackers

From Alexandre Felipe
Subject Re: SLOPE - Planner optimizations on monotonic expressions.
Date
Msg-id CAE8JnxP__hhKjP8uXKqGepg+GAjRy+Jthg=f-e24G3PML7ZdbA@mail.gmail.com
Whole thread Raw
In response to Re: SLOPE - Planner optimizations on monotonic expressions.  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: SLOPE - Planner optimizations on monotonic expressions.
List pgsql-hackers

I know it is less than a week from the end of the commitfest,
does it make sense to reduce the scope of this to get it in an
acceptable condition?

#1 GROUP BY
What motivated me to get this was queries with
GROUP BY date_trunc(x, timestamp)
GROUP BY timestamp::date
I tried to cover as many functions as possible, as I don't know how 
other people might be creatively writing their queries.

#2 JOIN
There might be some joins that can be made a merge join
but that is not a big deal, and makes it much more complicated
happy to drop.

#3 ORDER BY
This case is a bit pointless, if we are ordering by f(x) we could
simply order by x and still use f(x) in the query. But is there
because I use the pathkey to get the grouping correct.

#3 min/max
This is a nice case where min(f(x)) is computed by an index scan
with limit 1, but again, one can simply use f(min(x)) to get the same
plan.

#4 Recursive slope analysis
While the recursive slope analysis is very elegant I know that 
a lot of eyebrows will raise with a 15% planning time increase.
So I am happy to restrict this to the queries with GROUP BY
clause.

#5 Alternative explicit monotonicity
If you think that this is better, we could add two functions
increasing(x, f(x)) returns f(x)
decreasing(x, f(x)) returns f(x) 
at planning time we accept the index paths, and at 
run time we could check that the result does not violate the order
this could be even more general, e.g.

SELECT increasing(x, abs(x)) WHERE x >= 0
GROUP BY 1;

SELECT increasing(x, x * y) WHERE y >= 0
GROUP BY 1;

Do any of these give a good chance to have this in this commitfest
or should I just chill out?


On Thu, Mar 26, 2026 at 6:17 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
On Wed, 25 Mar 2026 at 23:35, Alexandre Felipe
<o.alexandre.felipe@gmail.com> wrote:
>
> Good catch,
> Can you think of any other type that would wrap,

Arithmetic with intervals isn't monotonic in general because of the
way interval time units vary. 
 
For example, '1 month - 29 days' is "positive" (in the sense that it
compares as greater than zero, and it compares equal to an interval of
'1 day'), but adding it to a date or timestamp may go forwards or
backwards, or not move at all, depending on the number of days in the
month.

Now that you say it makes sense.

So ordering by an interval column can produce different results than
ordering by a fixed date/timestamp plus the interval.

Removing interval arithmetic

Regards,
Alexandre
 

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: BM_IO_ERROR flag is lost in TerminateBufferIO due to order of operations in UnlockBufHdrExt
Next
From: Nathan Bossart
Date:
Subject: Re: Speed up COPY TO text/CSV parsing using SIMD