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