wieck@debis.com (Jan Wieck) writes:
> I think the best place for it will be at the top of the
> optimizer. It's more an optimization issue even if
> implemented in rewriting technique.
I have thought for some time that we need an additional phase in between
the rewriter and the planner/optimizer proper. This phase would be the
right place to do constant-subexpression folding, cnfify(), and any
other rearrangements of the parse tree that would be likely to help the
planning process. So far, the only specific example I had in mind was
the index restriction clauses that are added for LIKE and ~ matches with
a constant initial pattern --- those are currently done by gram.y but
I think they need to happen much later. If this idea of propagating
restriction clauses across a join is really worthwhile, then this new
optimization phase would be the right place for that too.
The reason I'd prefer to keep it separate from the rewriter is that the
rewriter is mostly concerned with functionality (implementing views etc)
whereas this new module would be concerned with optimization. Obviously
you do not want to start worrying about optimization until you've got
the fully expanded query available.
regards, tom lane
