Jules Bean <jules@jellybean.co.uk> writes:
> Presumably then, the optimizer doesn't even know that + is
> commutative, so it can't fold the constant in (5 + a + 4).
Actually, it does know that + is commutative, courtesy of the oprcom
column in pg_operator. But it doesn't know that + is associative,
which is something you must also assume to transform 5 + a + 4
(really (5 + a) + 4 in the parser output) into a + (5 + 4).
Since, in general, the associative law does NOT hold for computer
arithmetic (think about intermediate-result overflow, not to mention
roundoff error in floating-point cases), I'm hesitant to want to put
such assumptions in.
But the more serious problem is the search space involved in discovering
that there is a path of manipulations that leads to a more completely
reducible expression. With a large expression that could be an
exponential time cost --- even if the resultant savings is zero.
I do not buy your previous comment that the cost of optimization is
negligible. We've already had to put in heuristics to prevent the
system from blowing up in cnfify() for moderately large WHERE clauses
--- it used to be that a few dozen OR (a=1 AND b=2) OR (a=4 AND b=5)
kinds of clauses would bring the optimizer to its knees. And that's
for a well-understood deterministic simplification that affects only
AND/OR/NOT operators, with no search involved to decide what to do
with them. What you're proposing would affect many more operators
and require a combinatorial search to see what could be done to the
expression.
So I stand by my opinion that this isn't likely to be a profitable
path to pursue.
regards, tom lane