This is the time of year when the Wisconsin Courts formalize their annual plan for where people will be spending the bulk of their time in the coming year. Two years ago at this time, managers decided that serializable transactions were a big enough issue to justify assigning about half of my 2011 time to working on PostgreSQL enhancements for that. This year our big database issue is materialized views. As we strive to create our next generation of software we find ourselves wanting to provide "dashboard" type windows with graphs of statistics which are insanely expensive to calculate on the fly. We've been creating ad hoc materialized views to deal with the performance issues, but that is labor intensive. I'm considering submitting a proposal to management that I be assigned to work on a declarative implementation in PostgreSQL to allow speedier application development of software needing materialized views. I'm posting to make sure that nobody else is already in the midst of working on this, and to check regarding something on the Wiki page for this topic: http://wiki.postgresql.org/wiki/Materialized_Views 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? I'm not at the point of proposing specifics yet; the first phase would be a close review of prior threads and work on the topic (including the GSoC work). Then I would discuss implementation details here before coding. The hope on our end, of course, is that the time spent on implementing this would be more than compensated by application programmer time savings as we work on our next generation of application software, which seems like a pretty safe bet to me. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
