On Tue, Nov 8, 2011 at 9:23 PM, Kevin Grittner <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
