Peter Eisentraut <peter_e@gmx.net> wrote:
> On 2/19/13 5:47 PM, Kevin Grittner wrote:
>> When I went to do this, I hit a shift/reduce conflict, because
>> with TABLE being optional it couldn't tell whether:
>>
>> TRUNCATE MATERIALIZED VIEW x, y, z;
>>
>> ... was looking for five relations or three. That goes away
>> with MATERIALIZED escalated to TYPE_FUNC_NAME_KEYWORD. Is that
>> OK?
>
> Is TRUNCATE even the right command here? For regular tables
> TRUNCATE is a fast DELETE, which logically empties the table.
> For materialized views, there is no deleting, so this command (I
> suppose?) just invalidates the materalized view. That's not the
> same thing.
Hmm. That's what Greg Stark just said, and I replied that nobody
else had raised the issue in over three months. With Greg, that's
two now.
TRUNCATE MATERIALIZED VIEW discards any data which has been loaded
into the MV, rendering it unavailable for scanning. Internally, it
does do a truncate, exactly as truncate table. The resulting
zero-length heap file is what is used to determine whether a
materialized view is "scannable". When a CREATE WITH DATA or a
REFRESH generates zero rows, an empty single page is created to
indicate that it is scannable (valid to use in queries) but
contains no rows.
I agree that INVALIDATE is probably more descriptive, although it
seems that there might be some even better word if we bikeshed
enough. The question is, is it worth creating a new keyword to
call the internal truncate function for materialized views, versus
documenting that truncating a materialized view renders it invalid?
Again, given the numbers that Tom presented a while back about the
space requirements of every new keyword, I don't think this is
enough of a gain to justify that. I still squirm a little about
having used REFRESH, even though demand for that was overwhelming.
> Are there TRUNCATE triggers on materialized views?
No. Nor SELECT, INSERT, UPDATE, or DELETE triggers. You can't
create a trigger of any type on a materialized view. I don't think
that would interfere with event triggers, though.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company