materialized-views

I am loading a bunch of data into a PostgresQL 9.3 database and then I want to refresh all materialized views that depend on the updated tables. Is there a way to do it automatically instead of going through each view and refreshing them one by one? I know that Oracle can do that rather easily but I did not find anything after combing through PostgreSQL documentation. Looks like current version of PostgreSQL (9.3.1) does not have such functionality, have had to write my own function instead: CREATE OR REPLACE FUNCTION RefreshAllMaterializedViews(schema_arg TEXT DEFAULT 'public') RETURNS INT AS

I have a materialized view defined this way: CREATE MATERIALIZED VIEW M_FOO REFRESH COMPLETE ON COMMIT AS SELECT FOO_ID, BAR FROM FOO WHERE BAR IS NOT NULL GROUP BY FOO_ID, BAR / COMMENT ON MATERIALIZED VIEW M_FOO IS 'Foo-Bar pairs'; I wrote as a sort of cache: the source table is huge but the number of different pairs is fairly small. I need those pairs to get them JOINed with other tables. So far so good: it absolutely speeds queries. But I want to make sure that the view does not contain obsolete data. The underlying table is modified four or five times per month but I don't necessarily

How to implement Materialized Views? If not, how can I implement Materialized View with MySQL? Update: Would the following work? This doesn't occur in a transaction, is that a problem? DROP TABLE IF EXISTS `myDatabase`.`myMaterializedView`; CREATE TABLE `myDatabase`.`myMaterializedView` SELECT * from `myDatabase`.`myRegularView`; I maintain a project called Flexviews ( http://github.com/greenlion/swanhart-tools ) which adds incrementally refreshable materialized views to MySQL (aka fast refresh), even for views that use joins and aggregation. I've been working on this project for three years.

It's clear to me why a materialized view is preferable over just querying a base table. What is not so clear is the advantage over just creating another table with the same data as the MV. Is the only advantage to the MV really just the ease of creation/maintenance? Isn't an MV equivalent to a table with matching schema and an INSERT INTO using the MVs SELECT statement? Meaning, you can create an MV as follows CREATE MATERIALIZED VIEW ... AS SELECT * FROM FOO; And you can create an equivalent table: CREATE TABLE bar (....); INSERT INTO bar SELECT * FROM FOO; Not to say that ease of creation /

I created the Oracle Materialized View below: CREATE MATERIALIZED VIEW MyMV REFRESH COMPLETE ON DEMAND AS SELECT t1.* FROM table1 t1, table2 t2 where t1.id=t2.id; The table1 has a primary key and the MV was created succesfully but the primary key was not created in the materialized view table. Is there any other way to create MVs with primary keys? it's because your materialized view is based on two tables, if you create your view based on a single table with a primary key, then the primary key is created on you Materialized view. You can still create the index afterwards if you need one: SQL>

I'm trying to create a subset of a table (as a materialized view), defined as those records which have a matching record in another materialized view. For example, let's say I have a Users table with user_id and name columns, and a Log table, with entry_id, user_id, activity, and timestamp columns. First I create a materialized view of the Log table, selecting only those rows with timestamp > some_date. Now I want a materliazed view of the Users referenced in my snapshot of the Log table. I can either create it as select * from Users where user_id in (select user_id from Log_mview) or I can do

I have a huge materailized view that I have to adjust. It's a simple adjustment as I'm just adding an NVL function to the select statement. I.e. Original... Select this, that..... I.e. Modified Select NVL(this, orThat) as this, NVL(That, orThis) as that The query takes 26 seconds to run, but due to the amount of rows retrieved (2.3 million) it is dead slow. It ran for almost 5 days straight and then I stopped it. This is a problem, especially since I need to deliver this to a client, and they can't run a script for 5+ days to create a MV. Question: Is there any way to speed up the altering

I have a very complex Oracle view based on other materialized views, regular views as well as some tables (I can't "fast refresh" it). Most of the time, existing records in this view are based on a date and are "stable", with new record sets having new dates. Occasionally, I receive back-dates. I know what those are and how to deal with them if I were maintaining a table, but I would like to keep this a "view". A complete refresh would take around 30 minutes, but it only takes 25 seconds for any given date. Can I specify that only a portion of a materialized view should be updated (i.e. the