On Mon, Apr 12, 2010 at 3:43 PM, Greg Smith <g...@2ndquadrant.com> wrote: > Josh Berkus wrote: >> >> There are basically 2 major parts for materialized views: >> A) Planner: Getting the query planner to swap in the MatView for part of >> a query automatically for query plan portions which the MatView supports; >> B) Maintenance: maintaining the MatView data according to the programmed >> scheme (synch, asynch, periodic). >> > > I'm run more into problems where it's perfectly fine to specify using the > materialized view directly in the query, but keeping that view up to date > usefully was the real problem. The whole idea of getting a MV used > automatically is valuable, but far down the roadmap as I see it. > > Not everyone would agree of course, and your description does suggest a > better way to organize a high-level summary though; here's a first cut: > > 1) Creation of materalized view > Current state: using "CREATE TABLE AS" or similar mechanism, maintain > manually > Optimal: "CREATE MATERIALIZED VIEW" grammar, metadata to store MV data, > dump/reload support > > 2) Updating materialized views > Current state: periodically create new snapshots, or maintain using > triggers > Optimal: Built-in refresh via multiple strategies, with minimal locking as > to improve concurrent access > > 3) Using materialized views in the planner > Current state: specify the manually created MV in queries that can use it > Optimal: Automatically accelerate queries that could be satisfied by > substituting available MVs > > With (1) being what I think is the only GSoC sized subset here. > > I'm not saying someone can't jump right into (3), using the current > implementations for (1) and (2) that are floating around out there. I just > think it would end up wasting a fair amount of work on prototypes that don't > work quite the same way as the eventual fully integrated version. You > certainly can start working on (3) without a fully fleshed out > implementation of (2), I don't know that it makes sense to work on before > (1) though.
Good summary. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers