diff options
author | Kevin Grittner <kgrittn@postgresql.org> | 2013-03-03 18:23:31 -0600 |
---|---|---|
committer | Kevin Grittner <kgrittn@postgresql.org> | 2013-03-03 18:23:31 -0600 |
commit | 3bf3ab8c563699138be02f9dc305b7b77a724307 (patch) | |
tree | a36ddfded0bea88ee863595f58f62661cc61948b /src/backend/commands/cluster.c | |
parent | b15a6da29217b14f02895af1d9271e84415a91ae (diff) |
Add a materialized view relations.
A materialized view has a rule just like a view and a heap and
other physical properties like a table. The rule is only used to
populate the table, references in queries refer to the
materialized data.
This is a minimal implementation, but should still be useful in
many cases. Currently data is only populated "on demand" by the
CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements.
It is expected that future releases will add incremental updates
with various timings, and that a more refined concept of defining
what is "fresh" data will be developed. At some point it may even
be possible to have queries use a materialized in place of
references to underlying tables, but that requires the other
above-mentioned features to be working first.
Much of the documentation work by Robert Haas.
Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja
Security review by KaiGai Kohei, with a decision on how best to
implement sepgsql still pending.
Diffstat (limited to 'src/backend/commands/cluster.c')
-rw-r--r-- | src/backend/commands/cluster.c | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c index c0cb2f66545..8ab8c175195 100644 --- a/src/backend/commands/cluster.c +++ b/src/backend/commands/cluster.c @@ -29,6 +29,7 @@ #include "catalog/namespace.h" #include "catalog/toasting.h" #include "commands/cluster.h" +#include "commands/matview.h" #include "commands/tablecmds.h" #include "commands/vacuum.h" #include "miscadmin.h" @@ -379,6 +380,19 @@ cluster_rel(Oid tableOid, Oid indexOid, bool recheck, bool verbose, check_index_is_clusterable(OldHeap, indexOid, recheck, AccessExclusiveLock); /* + * Quietly ignore the request if the a materialized view is not scannable. + * No harm is done because there is nothing no data to deal with, and we + * don't want to throw an error if this is part of a multi-relation + * request -- for example, CLUSTER was run on the entire database. + */ + if (OldHeap->rd_rel->relkind == RELKIND_MATVIEW && + !OldHeap->rd_isscannable) + { + relation_close(OldHeap, AccessExclusiveLock); + return; + } + + /* * All predicate locks on the tuples or pages are about to be made * invalid, because we move tuples around. Promote them to relation * locks. Predicate locks on indexes will be promoted when they are @@ -901,6 +915,10 @@ copy_heap_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, get_namespace_name(RelationGetNamespace(OldHeap)), RelationGetRelationName(OldHeap)))); + if (OldHeap->rd_rel->relkind == RELKIND_MATVIEW) + /* Make sure the heap looks good even if no rows are written. */ + SetRelationIsScannable(NewHeap); + /* * Scan through the OldHeap, either in OldIndex order or sequentially; * copy each tuple into the NewHeap, or transiently to the tuplesort |