database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-02 09:02:37 +03:00
Code Activity

Add a materialized view relations.

Browse Source 
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.
This commit is contained in:
Kevin Grittner
2013-03-03 18:23:31 -06:00
parent b15a6da292
commit 3bf3ab8c56
103 changed files with 4238 additions and 436 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
src/backend/rewrite/rewriteHandler.c
View File

@ -1168,7 +1168,8 @@ rewriteTargetListUD(Query *parsetree, RangeTblEntry *target_rte,
const char *attrname;
TargetEntry *tle;
if (target_relation->rd_rel->relkind == RELKIND_RELATION)
if (target_relation->rd_rel->relkind == RELKIND_RELATION ||
target_relation->rd_rel->relkind == RELKIND_MATVIEW)
{
/*
* Emit CTID so that executor can find the row to update or delete.
@ -1590,6 +1591,23 @@ fireRIRrules(Query *parsetree, List *activeRIRs, bool forUpdatePushedDown)
*/
rel = heap_open(rte->relid, NoLock);
/*
* Skip materialized view expansion when it is being created.
*
* NOTE: This is assuming that we cannot have gotten to this point
* with a non-scannable materialized view unless it is being
* populated, and that if it is scannable we want to use the existing
* contents. It would be nice to have some way to confirm that we're
* doing the right thing here, but rule expansion doesn't give us a
* lot to work with, so we are trusting earlier validations and
* execution steps to get it right.
*/
if (rel->rd_rel->relkind == RELKIND_MATVIEW && rel->rd_isscannable)
{
heap_close(rel, NoLock);
break;
}
/*
* Collect the RIR rules that we must apply
*/