Re: Postgresql Materialized views

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

In response to

Responses

Browse pgsql-hackers by date

  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