Re: [HACKERS] Early evaluation of constant expresions (with PATCH)

frankpit@pop.dn.net writes:
> Tom Lane wrote:
>> This is something I had on my own to-do list, and I'm glad to see
>> someone beat me to it.  But you've only done half the job: you
>> should also be folding operators with constant arguments.

> I actually do the operators as well, and also boolean operators (which
> are handled by special Expr nodes).

(Hangs head...)  Yup.  That's what I get for opining after a fast
late-night scan of a patch.  Relying on ExecEvalExpr is a good hack ---
the patch is much smaller than I would've guessed.  (Actually, now
that I look at it, it looks like the functions rather than the
operators are missing the necessary preinitialization.  Perhaps at
the place where you chose to put this in, setFcache has already
been done?)

There are additional smarts that could/should be put in, though.
In particular, I think we should be smarter about AND and OR clauses.
If *any* of the inputs to an AND are a constant FALSE, you can collapse
the node and not bother computing the other subexpressions; likewise
a constant TRUE input to an OR allows short-circuiting.  (I have seen
queries, primarily machine-generated ones, where this would be an
enormous win.)  Contrariwise, constant TRUE/FALSE inputs can simply be
dropped, and the AND or OR operator eliminated if only one nonconstant
input remains.  This is the reason why I think there is an interaction
with cnfify(): it rearranges the AND/OR structure of the tree and might
expose --- or hide --- opportunities of this kind.  (BTW, it might be a
good idea to do the first pass of cnfify, namely AND/OR flattening,
before trying to apply this simplification.)

Also, most operators and functions can be collapsed to NULL if any of
their inputs are NULL, although I don't think we can risk making that
optimization without adding a flag to pg_proc that tells us if it is OK.

>> Also, you need to be wary of functions like now() and random().
>> There probably isn't any other way to handle these than to add a
>> column to pg_proc flagging functions that can't be constant-folded.

> I puzzled over case of now() for a while but I don't think that it
> raises a problem.

No, you can't just define the problem away by saying that whatever
behavior is convenient to implement is acceptable.  It's true that
now() is not really a problem, because it's defined to yield the
start time of the current transaction, and therefore is effectively
a constant *within any one transaction*.  But random() *is* a problem,
and user-defined functions could be a problem.  SQL functions probably
shouldn't be folded either (not quite sure of that).

Bruce points out in another reply that the proiscachable field of
pg_proc is intended for exactly this purpose.  It hasn't been kept
up carefully because no extant code uses it, and in fact hardly any
of the standard entries in pg_proc are marked iscachable, which is
obviously silly.  But we could certainly go through pg_proc and set
the flag on everything except the danger items.

> Another factor about positioning of the filter that I was uncertain
> about was time expense.  Is the time taken by multiple tree walks in
> the planner very significant in the overall scheme of things?

I don't think you need to worry about anything that has cost linear in
the size of the expression tree.  Up till a couple weeks ago we had some
code in cnfify() that used space and time exponential in the size of the
tree :-( ... now it's down to O(N^2) which is still a bottleneck for
complex query expressions, but O(N) is not to be worried about.  Like
I said, I wouldn't object to running this code twice on a qual.

There are some upstream places where it would be nice too --- for
example, coercion of DEFAULT expressions would be best handled by
sticking a type-conversion function atop the given parsetree and then
seeing if this code would simplify it.  We'll definitely need to make
use of proiscachable to make that safe, however.
        regards, tom lane