> I would like to know what operations you plan to support independently > of the command names. I may have missed much earlier in the discussion > but then I suspect things have evolved since then. > > It sounds like you want to support: > > 1) Selecting from materialized viws > 2) Manually refreshing materialized views > 3) Manually truncating materialized views
Maybe plus? 4) Automatically dropping materialized views if underlying table(s) are dropped/altered Or this has to be done manually? > And explicitly not support > > 1) Automatically rewriting queries to select from matching views > 2) Incrementally refreshing materialized views > 3) Manual DML against data in materialized views (except truncate > which is kind of DDL) > 4) Keeping track of whether the data in the materialized view is up to date > > I have to say I find this model a bit odd. It seems the UI you're > presenting is that they're basically read-only tables that the > database will fill in the data for automatically. My mental model of > materialized views is that they're basically views that the database > guarantees a different performance characteristic for. > > I would expect a materialized view to be up to date all the time. If > we don't support incremental updates (which seems like a fine thing > not to support in a first cut) then I would expect any DML against the > table to mark the view invalid and any queries against it to produce > an error (or possibly go to the source tables using the view > definition but that's probably a bad idea for most use cases). Ie. > they should behave like a view at all times and have up to date > information or fail entirely. > > I would expect a command like TRUNCATE MATERIALIZED VIEW to exist but > I would expect it to be called something like INVALIDATE rather than > TRUNCATE and dropping the storage is a side effect of simply telling > the database that it doesn't need to maintain this materialized view. > Though I could be convinced "truncate" is a good name as long as it's > documented well. > > -- > greg > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
