Greg Stark <st...@mit.edu> wrote: > Kevin Grittner <kgri...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers