Re: Materialized views WIP patch - Mailing list pgsql-hackers
From | Greg Stark |
---|---|
Subject | Re: Materialized views WIP patch |
Date | |
Msg-id | CAM-w4HNwDzC+f9RapEw6-Su9BmtGi6WUaaJP54cN1J3gyapMFg@mail.gmail.com Whole thread Raw |
In response to | Re: Materialized views WIP patch (Kevin Grittner <kgrittn@ymail.com>) |
Responses |
Re: Materialized views WIP patch
Re: Materialized views WIP patch Re: Materialized views WIP patch |
List | pgsql-hackers |
On Wed, Feb 20, 2013 at 4:26 PM, Kevin Grittner <kgrittn@ymail.com> wrote: > Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >> The way to fix it is to not try to use the sub-production but spell it >> all out: >> >> TRUNCATE TABLE relation_expr_list ... >> | TRUNCATE MATERIALIZED VIEW relation_expr_list ... >> | TRUNCATE relation_expr_list ... >> >> Now the parser doesn't have to make any shift-reduce decision until >> after it can "see past" the first identifier. It's a bit tedious >> but beats making a word more reserved than it has to be. > > Thanks! Will do. Fwiw I think worrying about stuff like this at this point is probably a waste of time. There'll be a period of bike-shedding where people debate what the command should be called so worrying about parser conflicts before there's a consensus is kind pointless. 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 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
pgsql-hackers by date: