Re: 9.6 -> 10.0 - Mailing list 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