From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Optimize constant MinMax expressions |
Date: | 2018-12-29 23:36:38 |
Message-ID: | 7866.1546126598@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-12-29 23:56:17 | Re: Poor buildfarm coverage of strong-random alternatives |
Previous Message | legrand legrand | 2018-12-29 23:27:18 | Planning counters in pg_stat_statements (using pgss_store) |