Re: 9.6 -> 10.0
От | Robert Haas |
---|---|
Тема | Re: 9.6 -> 10.0 |
Дата | |
Msg-id | CA+Tgmoa996oXjonWPiqX8uas5q_Of7_TDNyRZhHxoKxWmnNYhg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 9.6 -> 10.0 ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: 9.6 -> 10.0
(Justin Clift <justin@postgresql.org>)
Re: 9.6 -> 10.0 ("Joshua D. Drake" <jd@commandprompt.com>) Re: 9.6 -> 10.0 (David G Johnston <david.g.johnston@gmail.com>) |
Список | pgsql-advocacy |
On Mon, Apr 11, 2016 at 11:29 AM, Joshua D. Drake <jd@commandprompt.com> wrote: > (note there are a couple that are obvious, heap metapage, optimise FSM > etc...) But it's not obvious why those things require breaking compatibility, and pgsql-advocacy is not the right mailing list to discuss that. There has been no recent discussion of any of this on pgsql-hackers. Basically, this discussion boils down to Simon suggesting that instead of bumping the version to 10.0 when we have a particularly good release with great features, as we did for 9.0 and 8.0, we should instead do it when we're planning to make a large compatibility break, something which the community has not agreed to do. Moreover, as somebody already pointed out upthread, if we do decide to do that at some point, calling this release 10.0 doesn't preclude us from making the big compatibility break 11.0, if and when it happens. So instead of talking about whether the features in 9.6 are good enough that it deserves to be called 10.0, we've veered into talking about whether we want to break compatibility at some point, which is a weird discussion for an advocacy list to be having. TBH, I kind of expected that 9.5 was going to end up being 10.0, since we haven't had a second digit of "5" since the 6.x series of releases. I think that 9.5 was a pretty good release - INSERT .. ON CONFLICT is exciting, and BRIN and RLS are good too - but I think 9.6 is going to be better. I am of course biased, but I think parallel query - now including parallel aggregate - is a great headline feature. But we've also got two other things that I think are really big. First, we've got synchronous_commit=remote_apply and multiple synchronous standbys, so you can now set up a streaming replication cluster and get answers from your read standbys that are guaranteed to reflect the latest commits on the master. Second, we've got a freeze map so that your large database doesn't spend all of it's time uselessly re-freezing, which should make it possible to run PostgreSQL on much larger data sets. That goes nicely with the fact that we also have a bunch of scalability enhancements for many-socket machines, which are the sort of machines where those larger data sets would perhaps be stored. Apart from those big three (parallel query, remote_apply+multiple sync standbys, freeze map), there are lots of other things and which one is best will probably depend on taste, but they include a bunch of nifty performance enhancements for postgres_fdw, snapshot too old to control table bloat, pluggable index access methods including bloom indexes as a sample implementation, ability to see lwlocks in pg_stat_activity, VACUUM progress reporting, enhancements to index-only scans, phrase full text search, k-nearest-neighbor support for the cube extension, and a bunch of other stuff. So, I think it's shaping up to be pretty great release. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-advocacy по дате отправления: