Re: SLOPE - Planner optimizations on monotonic expressions.

From: Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: SLOPE - Planner optimizations on monotonic expressions.
Date: 2026-07-03 10:02:30
Message-ID: CAE8JnxOPJispcdhWz2TB1V_4L788nCipQcTFjjg4MW+OwLgJqg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 1, 2026 at 11:00 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
wrote:

> Apologies for the late response, somehow I missed this update.
>

Thank you for your late response :D

> The changes generally look good and seem to work, except one remaining
> issue with domains:

I didn't know about domains before, tempting
e.g. cos(pi * x) decreasing for x between 0 and 1.
But I will avoid that rabbit hole.

The solution I implemented was using getBaseType
./src/backend/utils/cache/lsyscache.c:2754:getBaseType(Oid typid)

+ if(var_type >= FirstNormalObjectId)
+ var_type = getBaseType(var_type);

/*
> * get_const_sign
> * Helper to determine the sign of a numeric constant.
> * Returns 1 for positive, -1 for negative, 0 for zero or
> unknown.
> */
> -static int
> +static inline enum NUMERIC_SIGN
>
> This comment is now outdated. The default value is unreachable
> currently, but is 0 still a safe value there?
>

Updated, actually NUMERIC_SIGN_ZERO indicates that the value
is strictly equals to 0, I don't see how it would be unsafe.

> +enum NUMERIC_SIGN {
> + NUMERIC_SIGN_NINF=-2,
> + NUMERIC_SIGN_NEG=-1,
> + NUMERIC_SIGN_ZERO=0,
> + NUMERIC_SIGN_POS=1,
> + NUMERIC_SIGN_PINF=3,
> + NUMERIC_SIGN_NAN=4,
> + NUMERIC_SIGN_NULL=5,
> +};
>
> this is missing a typedef and maybe it should be defined at the
> beginning of the file or in a header? Is skipping positive 2
> intentional?
>

OK, moved to the top with a typedef, the 2 gap was not intentional,
I think when I wrote it I had NaN there before +Infinity, but later
I realised that NaN goes after +Infinity.

> The patchset also has many small formatting issues/inconsistencies,
> maybe it would be worth to run pgindent on it?
>

I ran it on src/backend/utils/adt/misc.c

It kept changing
/*
* arg0_asc_slope_support
* Prosupport: f(x, ...) is monotonically increasing in x.
*/
to
/*
* arg0_asc_slope_support Prosupport: f(x, ...) is monotonically increasing
* in x.
*/

Is there a written standard/recommendation for these, maybe
/*
* arg0_asc_slope_support
*
* Prosupport: f(x, ...) is monotonically increasing in x.
*/

The last part of the slope test is checking 480 corner cases, in my machine
it takes 240ms while some other tests take 1000+ so I guess it is not a
problem.

Regards,
Alexandre

Attachment Content-Type Size
v9-0003-SLOPE-prosupport-definitions.patch application/octet-stream 10.2 KB
v9-0004-SLOPE-catalog-changes.patch application/octet-stream 84.9 KB
v9-0001-benchmark.patch application/octet-stream 4.8 KB
v9-0005-SLOPE-Planner-support.patch application/octet-stream 39.2 KB
v9-0002-Optimized-reverse-pathkeys.patch application/octet-stream 6.2 KB
v9-0007-FIX-NaN-special-cases.patch application/octet-stream 36.5 KB
v9-0006-SLOPE-redundancy-checks.patch application/octet-stream 14.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2026-07-03 10:10:33 Re: hashjoins vs. Bloom filters (yet again)
Previous Message Zhijie Hou (Fujitsu) 2026-07-03 09:56:13 RE: Re-read subscription state after lock in AlterSubscription