Re: Materialized views

On Tue, Nov 8, 2011 at 9:23 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:

> That page describes three components: creating MVs, updating MVs, and
> having the planner automatically detect when an MV matches some
> portion of a regular query and using the MV instead of the specified
> tables in such cases.  I have high confidence that if time is
> approved I could do the first two for the 9.3, but that last one
> seems insanely complicated and not necessarily a good idea.  (That's
> particularly true with some of the lazier strategies for maintaining
> the data in the materialized view.)  I don't think we want to use
> that 3rd component in our shop, anyway.  So the question is, would a
> patch which does the first two without the third be accepted by the
> community?

For me, yes. I support and encourage your work. It's a big topic and
we must approach it incrementally.

Having said that, we should assume that #3 will be implemented and
that we need to collect appropriate metadata and anything else
required. So the design should foresee #3 and not in any way optimise
for the case where #3 doesn't happen. It may occur that #3 is added
during next cycle concurrently with this development.

I would also caution that all other databases currently provide #3 as
a matter of course. That is the "sauce" as far as many people are
concerned. Everything else is already achievable using external
application code. So I would not want people to start saying "we have
MVs" when in fact all we did was add declarative syntax to support
what was already possible - we could easily publicise that incorrectly
at release time.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services