by a DBMS
ever gets a logical
algebra query tree.
the query must be parsed,
checked to make sure
that it's legal and
its referenced views must be resolved.
If the data model is SQL,
the DBMS must deal with nested subqueries.
Some of these functions are best left to the parser.
But other functions could be handled by the optimizer itself
or by a pre-optimization
give nested queries
to the optimizer without modification
-- moving the problem
to the optimizer --
the nested and unnested versions
of the query
and chose the cheapest,
or we could develop
a rewrite or tenderization phase which would
after the parser,
but before the optimizer.
discuss a "novel"
phase of query optimization
precede the optimization proper,
that they call query rewrite.
It is rule-based,
like many optimizers,
but heuristic in the sense
does not consider
calculated (i.e. estimated) costs
during the rewrite process.
(The consequent of a rule
is always assumed to be the best,
as opposed to
at some point
comparing its cost
to the cost of the antecedent.)
is able to
merge views into the original query,
transform quantified (nested)
subqueries into single query blocks with additional joins,
and add keys to certain intermediate tables
to allow duplicate elimination to occur early,
reducing cardinalities of non-unique tables.
One motivation for putting the
rewrite rules in a pre-optimization phase
instead of in the optimizer proper,
is to prevent
rule or search space explosion
or other difficulties
the rewrite rules