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 CAE8JnxOPJispcdhWz2TB1V_4L788nCipQcTFjjg4MW+OwLgJqg@mail.gmail.com
Whole thread
In response to Re: SLOPE - Planner optimizations on monotonic expressions.  (Zsolt Parragi <zsolt.parragi@percona.com>)
Responses Re: SLOPE - Planner optimizations on monotonic expressions.
List pgsql-hackers
On Wed, Jul 1, 2026 at 11:00 PM Zsolt Parragi <zsolt.parragi@percona.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

pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Re-read subscription state after lock in AlterSubscription
Next
From: Tomas Vondra
Date:
Subject: Re: hashjoins vs. Bloom filters (yet again)