From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Zeugswetter Andreas ADI SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> |
Cc: | "Mark Mielke" <mark(at)mark(dot)mielke(dot)cc>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, Jean-Michel Pouré <jm(at)poure(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Postgresql Materialized views |
Date: | 2008-01-14 15:54:22 |
Message-ID: | 14479.1200326062@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Zeugswetter Andreas ADI SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> writes:
> Traditionally materialized views exist, so that you do not need to code differently.
> Your queries still run on the detail table, but are silently answered
> by a suitable MV. The MV might have count + other aggregated columns
> grouped by some columns, and thus be able e.g. shortcircuit a
> "select count(*) from atab". The MV should be MVCC aware (have different
> values for different snapshots) and not substantially reduce possible
> concurrency of updates to the base table.
Note that you just raised the minimum bar for implementation of the
feature by a couple orders of magnitude. We cannot automatically
substitute an MV into queries unless this is guaranteed not to change
the results. No lazy updates, MVCC transparency required, etc.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-01-14 16:03:06 | Re: could not open relation: Invalid argument |
Previous Message | Tom Lane | 2008-01-14 15:36:08 | Re: Index trouble with 8.3b4 |