I have a table in Postgres that needs to have a column data type changed from float to numeric(10,2). However, there are 17 materialized views that have been created on this table by different owners, and I need to make sure that the materialized views are not refreshed while I make the change.
Is there a way to temporarily pause the materialized views from refreshing on Postgres, so that I can make the change to the table without breaking the views?
I am using AWS Aurora Postgresql v9.3
Related
I'm working on a project which requires me to write a query to create a materialized view in PostgreSQL. My requirement is that How I can get PostgreSQL materialized view refresh history time for specific materialized view.
PostgreSQL does not store the time when an SQL statement like REFRESH MATERIALIZED VIEW is run.
Any attempt to rely on the file modification time of the underlying data file is in vain, as jobs like autovacuum may modify the file.
The only way to retain such information is to store the times when you run the statement in a table yourself.
An alternative could be to log all DDL statements (log_statement = 'ddl') and retrieve the information from the log file.
Main question: I have several views depending on a PostgreSQL/PostGIS table and a final materialized view created by querying the other views. I need a fast and updatable final result (i.e. MV) to use in a QGIS project.
My aim is to update the starting table by overwriting it with new (lots of) values and hopefully have update views and materialized view. I use QGIS DB Manager to overwrite existing table but I get an error because of mv depending on it. If I delete mv, overwrite table and then recreate mv everything is ok but I'd like to avoid manual operations as much as possible.
Is there a better way to reach my goal?
Another question: If I set a trigger to refresh a mv when I update/insert/delete values in a table, would it work even in case of overwriting entire table with a new one?
Refreshing a materialized view runs the complete defining query, so that is a long running and heavy operation for a complicated query.
It is possible to launch REFRESH MATERIALIZED VIEW from a trigger (it had better be a FOR EACH STATEMENT trigger then), but that would make every data modification so slow that I don't think that is practically feasible.
One thing that might work is to implement something like a materialized view that refreshes immediately “by hand”:
create a regular table for the “materialized view” and fill it with data by running the query
on each of the underlying tables, define a row level trigger that modifies the materialized view in accordance with the changes that triggered it
This should work for views where the definition is simple enough, for complicated queries it will not be possible.
We have a view that aggregates from a backing table. The idea is to reduce cpu load by using a pre-aggregated table, and to periodically refresh it with the following:
create new_backing_table (fill it)
begin
drop backingtable
rename new_backingtable to backingtable
commit
while in production. The latency caused by the refresh interval is acceptable. Incremental updates are possible but not desirable.
Anyone has a comment on this scheme ?
Check out materialized views. This may suit your use case. It can be used to store query results at creation then refreshed at a later time.
A materialized view is defined as a table which is actually physically stored on disk, but is really just a view of other database tables. In PostgreSQL, like many database systems, when data is retrieved from a traditional view it is really executing the underlying query or queries that build that view.
https://www.postgresql.org/docs/9.3/static/sql-creatematerializedview.html
I'm unfortunately getting stuck on database stuff with PostGreSQL..
I created some materialized views in two schemas "schema1" and "schema2". These materialized views work well.
Then I made a backup of my database with PgAdmin.
And finally, I restored that database in an other server.
But this does not work as expected : all the materialized views have not been created (whereas both tables and classic views of "schema1" and "schema2" did)...
Hence my question : is it possible to restore materialized views. And if yes, can PgAdmin do the trick ?
Thanks you !
It makes sense that PG won't include the calculated materialized view in the backup since they can be generated from the data in the tables.
This is explained in more detail on the answer to this question from the Database Admin SO
To get the materialized view populated again after the backup you could try refreshing it.
REFRESH MATERIALIZED VIEW mymatview;
If you need to keep the data as it was at the time each backup, then perhaps you could insert select it into a table before the backup operation.
If I don't plan to implement incremental updates for materialized views in Postgres, are there any advantages to using them over CREATE TABLE AS? From what I have read, when you refresh a materialized view, that view locks and is not readable. Since it's unavailable, it seems to have the same affect as dropping and recreating a table at the same rate you run refresh on a materialized view.
As of PostgreSQL 9.3.2 you also cannot use materialized view data as basis of UPDATE query.
So if you need to use this view as a basis of some updates then you are better of using regular tables.