Dave Page <dp...@pgadmin.org> wrote: > Kevin Grittner <kevin.gritt...@enterprisedb.com> wrote: >> Dave Page <dp...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers