Re: Optimize constant MinMax expressions

From: Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Optimize constant MinMax expressions
Date: 2018-12-30 08:31:48
Message-ID: e9fa8739-2612-98ab-b849-94c2ae5902e6@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30/12/2018 00:36, Tom Lane wrote:
> Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> writes:
>> I was working on a little thing where I needed to simulate BETWEEN
>> SYMMETRIC so naturally I used least() and greatest(). I was a little
>> surprised to see that my expressions were not folded into straight
>> constants and the estimates were way off as a consequence.
>
>> I came up with the attached patch to fix it, but it's so ridiculously
>> small that I fear I'm missing something.
>
> Well, the question this is begging is in the adjacent comment:
>
> * Generic handling for node types whose own processing is
> * known to be immutable, and for which we need no smarts
>
> Can we assume that the underlying datatype comparison function is
> immutable? I guess so, since we assume that in nearby code such as
> contain_mutable_functions_walker, but I don't think it should be done
> without at least a comment.

Adding a comment is easy enough. How is the attached?

> BTW, poking around for other code involving MinMaxExpr, I notice that
> contain_leaked_vars_walker is effectively assuming that all datatype
> comparison functions are leakproof, an assumption I find a bit debatable.
> Maybe it's all right, but again, it should certainly not have gone without
> a comment.

Surely this is out of scope for my patch?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Attachment Content-Type Size
optimize_constant_least_greatest.v02.patch text/x-patch 767 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2018-12-30 10:06:52 Re: pgsql: Use a separate random seed for SQL random()/setseed() functions.
Previous Message Pavel Stehule 2018-12-30 08:23:16 Re: PostgreSQL vs SQL/XML Standards