Dave Page <dpage@pgadmin.org> wrote:
> Kevin Grittner <kevin.grittner@enterprisedb.com> wrote:
>> Dave Page <dpage@pgadmin.org> wrote:
>>> In playing with materialized views, I noticed that they still
>>> seem to have an _RETURN rule implicitly created like a regular
>>> view.
>> A materialized view is pretty much like a view, but with the
>> results materialized.
>
> Yeah, I get that, but what is confusing is that this now seems to
> be a special kind of relation where there is an ON SELECT DO
> INSTEAD rule which isn't actually executed on SELECTs from the
> view but at some arbitrary time in the future.
Perhaps this way of looking at it will allow it to make sense: It
generates values which will be returned by SELECT -- it just does
that in advance and caches them on disk for quicker return when
queried.
As a practical matter, a materialized view needs to store exactly
the same information about its query, in the same form, as a
regular view. To add a new table to store this in a different
place, with references and such maintained in the same way, would
have multiplied the size of the patch with a lot of copy/pasted
code. I'm pretty sure the result would have been something which
was harder to review and maintain.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
