On Mon, Jun 3, 2013 at 3:59 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> 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.
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