Paul,

First, thanks for the summary of the Oracle implementation, very very
informative.

> Query rewrite
> =============
>
> <quote>The query optimizer automatically recognizes when an existing
> materialized view can and should be used to satisfy a request. It
> then transparently rewrites the request to use the materialized view.
> Queries go directly to the materialized view and not to the
> underlying detail tables. In general, rewriting queries to use
> materialized views rather than detail tables improves
> response.</quote>
>
> According to the figure in the text, the optimiser generates plans
> for both direct access and for using appropiate materialised views
> and picks the best option.
>
> I would welcome input on the algorithms that such an optimiser might
> use. I guess it could work by matching (sub-) RSE trees with all
> available materialised views in a combination of hashing ("is it
> based on the same base tables?") and brute force ("does it match?").
>
> Note that implementing query rewriting delivers 80% of the
> materialised view benefit to the end user, because IMHO doing a
> COMPLETE refresh on the summary tables, say every night, will do just
> fine in most cases.

Does query rewrite 'really' work with COMPLETE views?

Do data changes made since the COMPLETE refresh get reflected in the
query results? Or does the query report 'out-of-date' values?

It would seem incorrect for the query rewrite to use the view data which
is not up to date.

> PS For those who wonder: no, I am not implementing this -- it is
> *way* down on my "things I would like to do" list

Come on!!! It's just a day or two of coding! ;-)))


Sean