On Tue, Nov 8, 2011 at 9:23 PM, Kevin Grittner
<Kevin.Grittner@wicourts.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