From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Kevin Grittner <kevin(dot)grittner(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implicit rule created for materialized views |
Date: | 2013-06-03 15:43:10 |
Message-ID: | CA+OCxox5+JAOGqoKWMWcm7Q0GE-sc8=+CvuubhqbVuvkDrXtZg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 3, 2013 at 3:59 PM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> Kevin Grittner <kevin(dot)grittner(at)enterprisedb(dot)com> wrote:
>>> Dave Page <dpage(at)pgadmin(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Миша Тюрин | 2013-06-03 16:08:56 | Re: [HACKERS] high io BUT huge amount of free memory |
Previous Message | ktm@rice.edu | 2013-06-03 15:27:51 | Re: UTF-8 encoding problem w/ libpq |