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