materialized-views

问题 For general tables and views, I can see their data type by running the following query: select data_type from information_schema.columns where ..... However it does not seem that any information about materialized views appear here. I am able to get a list of columns for a materialized view by running: SELECT a.attname as column_name FROM pg_catalog.pg_attribute a INNER JOIN (SELECT c.oid, n.nspname, c.relname FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c

问题 I created a materialized view in Postgres 9.3 but I have since lost the underlying SELECT query that created it. I would like to DROP the materialized view, rewrite the query to include more data, and then CREATE a materialized view of the same name but with a new underlying query. 回答1: Just: SELECT pg_get_viewdef('myview'); from the client of your choice. e.g. in psql : test=> CREATE MATERIALIZED VIEW fred AS SELECT x FROM generate_series(1,100) x; SELECT 100 test=> \a\t Output format is

问题 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. 回答1: Looks like current version of PostgreSQL (9.3.1) does not have such functionality, have had to write my own function

问题 The official PostgreSQL 9.3 documentation on REFRESH MATERIALIZED VIEW does not yet describe it in detail. A quote from this blog: materialized views in Postgres 9.3 have a severe limitation consisting in using an exclusive lock when refreshing it. This basically blocks any attempts to read a materialized view while it is being refreshed with new data from its parent relations Another quote from a posting in the mailing list: if I understand things correctly REFRESH MATERIALIZED VIEW locks

问题 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

问题 I have a PostgreSQL DB, where I use materialized views. The problem occurs when I try to refresh these materialized views. REFRESH MATERIALIZED VIEW product_cat_mview; REFRESH MATERIALIZED VIEW productsforproject; My solution is, when the user want to see updated data, he should click a "refresh button" on the web page, but this takes about 50s (on a local connection and about 2 minutes from the application server) and all this time the user has to wait, which is not good. Now I should create

问题 I'm trying to optimize a query which uses a view in MySQL 5.1. It seems that even if I select 1 column from the view it always does a full table scan. Is that the expected behaviour? The view is just a SELECT "All Columns From These Tables - NOT *" for the tables I have specified in the first query below. This is my explain output from when i select the indexed column PromotionID from the query which makes up the view. As you can see it is vastly different from the output on the view. EXPLAIN

问题 Does PostgreSQL support computed / calculated columns, like MS SQL Server? I can't find anything in the docs, but as this feature is included in many other DBMSs I thought I might be missing something. Eg: http://msdn.microsoft.com/en-us/library/ms191250.aspx 回答1: Up to Postgres 11 generated columns are not supported - as defined in the SQL standard and implemented by some RDBMS including DB2, MySQL and Oracle. Nor the similar "computed columns" of SQL Server. STORED generated columns are

问题 I have the following materialized view - CREATE MATERIALIZED VIEW TESTRESULT ON PREBUILT TABLE WITH REDUCED PRECISION REFRESH FORCE ON DEMAND WITH PRIMARY KEY AS SELECT... FROM... WHERE... This materialized view has no backing MATERIALIZED VIEW LOG. As seen in the clause above this MV has "ON DEMAND" specifies, and according to Oracle documentation, "[ON DEMAND] indicate[s] that the materialized view will be refreshed on demand by calling one of the three DBMS_MVIEW refresh procedures." When

问题 This question already has answers here : Closed 8 years ago . Possible Duplicate: Why does this trigger fail? It says invalid identifier. CREATE MATERIALIZED VIEW ORDERS_MV BUILD IMMEDIATE REFRESH COMPLETE ON DEMAND AS SELECT * FROM ORDERS; CREATE OR REPLACE TRIGGER update_ship_receive INSTEAD OF INSERT ON ORDERS_MV FOR EACH ROW BEGIN UPDATE ORDERS SET EXPECTED_SHIP_DATE = ORDER_DATE+5; UPDATE ORDERS SET EXPECTED_RECEIVE_DATE = SHIP_DATE+1 WHERE SHIPPING_METHOD = '1 DAY'; UPDATE ORDERS SET