Greg Stark <stark@mit.edu> wrote:
> Kevin Grittner <kgrittn@ymail.com> wrote:
>> It doesn't. That was one of the more contentious points in the
>> earlier bikeshedding phases. Some felt that throwing away the
>> contents was a form of making the MV "out of date" and as such
>> didn't require any special handling. Others, including myself,
>> felt that "data not present" was a distinct state from
>> "generated zero rows" and that attempting to scan a materialized
>> view for which data had not been generated must result in an
>> error. The latter property has been maintained from the
>> beginning -- or at least that has been the intent.
>
> Actually this sounds like exactly what I was saying. I withdraw
> my concern entirely.
Reviewing your concerns and discussions of "freshness" in general
got me thinking -- while it is clear that not having generated
values in the MV based on its query clearly should make the view
non-scannable, and will be the only criterion for that in this
initial patch; later versions will almost certainly support
age-based conditions for whether the MV is scannable. So in the
next release the MV may become non-scannable based on the passage
of time since DML was run on a source table without the MV having
been refreshed or incrementally updated to reflect that DML. Which
makes me wonder why DML making the MV non-scannable is such a bad
thing in the case of TRUNCATE. Granted there is a difference in
that it is run *on the MV* rather than *on a source relation*; but
still, I'm having some second thoughts about that being a problem.
The problem with TRUNCATE MATERIALIZED VIEW from a logical
perspective doesn't seem to me so much that it makes the MV
non-scannable, as that it is the only DML which would be allowed
directly on an MV -- which is kind of a weird exception. It is
pretty much a given that when we can get to implementing it, DML
statements will render MVs unscannable under various conditions.
Josh Berkus and Greg Stark have been the most explicit about that,
but I think most of us who are interested in the feature take it as
a given.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
