On Mon, Jun 3, 2013 at 3:59 PM, Kevin Grittner <kgri...@ymail.com> wrote: > 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.
That perspective certainly makes it clearer. > 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. Yeah, I have no desire for that to be done. I'm just trying to understand what looked like some weirdness in the way it all worked. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: 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