Re: 9.3 Beta 1 Coming Soon!
От | Josh Berkus |
---|---|
Тема | Re: 9.3 Beta 1 Coming Soon! |
Дата | |
Msg-id | 516ED30C.9090400@agliodbs.com обсуждение исходный текст |
Ответ на | 9.3 Beta 1 Coming Soon! (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: 9.3 Beta 1 Coming Soon!
Re: 9.3 Beta 1 Coming Soon! |
Список | pgsql-advocacy |
> "Postgres developers and users believe that quality view support is an > important toolset for any database, and Postgres 9.3 includes several > improvements to it's view support. Enhancements included in this > release include the ability to create recursive views, to create > automatically updateable views, and limited support for built in > materialized views." I still think that's soft-pedaling it far to much. If we don't toot our own horn, who will? And "View improvements" is a pretty darned weak promotional message compared to "Materialized View Declaration". Regrading MatViews, let me explain why the Refresh locking isn't the albatross which some people think it is. Currently, my clients, and several OSS projects, have many applications which currently use tables as materialized views. The common way to handle these is "BEGIN; TRUNCATE matview; INSERT INTO matview SELECT ...; COMMIT;". This produces the *exact same* locking pattern as the current REFRESH. While more lock-sensitive patterns are possible, that doesn't mean people are, in the mainstream, using them. Thus 9.3 Matviews allow DB architects to do a task they have been doing, with simpler, less code, and no loss of functionality. Further, with simpler, more mainainable code, we can expect app developers who haven't previously used matviews as a concept to try them. Further, we'll have increases in functionality in the future (CONCURRENTLY in 9.4, async/sync updates later, incremental updates, etc.), which never would exist in an ad-hoc system, and which probably won't require any changes in code built on 9.3 to take advantage of. The purpose of advocacy, and release announcements, is to *promote* PostgreSQL, not to advertise every bug we have and every limitation. Nitpicky perfectionism may be useful when we're writing code, but it seriously undermines the project if it appears in our advocacy materials. What other open source DBMS even has the concept of materialized views? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-advocacy по дате отправления: