Re: 10.0 - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: 10.0
Date
Msg-id CABUevExsVgxvFJNE1xQQ-+jxvhyP3c=v_oe93=B=bH2cwtRAhQ@mail.gmail.com
Whole thread Raw
In response to Re: 10.0  (Andreas Joseph Krogh <andreas@visena.com>)
Responses Re: 10.0
List pgsql-hackers
On Fri, May 13, 2016 at 5:42 PM, Andreas Joseph Krogh <andreas@visena.com> wrote:
På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas <robertmhaas@gmail.com>:
Hi,

There is a long-running thread on pgsql-hackers on whether 9.6 should
instead be called 10.0.  Initially, opinions were mixed, but consensus
seems now to have emerged that 10.0 is a good choice, with the major
hesitation being that we've already released 9.6beta1, and therefore
we might not want to change at this point.  That doesn't seem like an
insuperable barrier to me, but I think it's now time for the
discussion on this topic to move here, because:

1. Some people who have strong opinions may not have followed the
discussion on pgsql-advocacy, and

2. If we're going to rebrand this as 10.0, the work will have to get done here.

The major arguments advanced in favor of 10.0 are:

- There are a lot of exciting features in this release.

- Even if you aren't super-excited by the features in this release,
PostgreSQL 9.6/10.0 is a world away from 10.0, and therefore it makes
sense to bump the version based on the amount of accumulated change
between then and now.

Thoughts?  Is it crazy to go from 9.6beta1 to 10.0beta2?  What would
actually be involved in making the change?
 
From a non-hacker...
 
From a DBA/application-developer perspective  while there are many exiting
features in 9.6 I'd expect more from 10.0, like some of these features:
- Built in "Drop-in replacement" Multi-master replication
- Built-in per-database replication with sequences and DDL-changes
  (future versions of pglogical might solve this)
- Full (and effective) parallelism "everywhere"
- Improved executor (like Robert Haas suggested), more use of LLVM or similar
- All of Postgres Pro's GIN-improvements for really fast FTS (with proper, index-backed, sorting etc.)
- Pluggable storage-engines


I'm willing to declare that the likelihood you getting all of these in one release is zero. And there will always be "one more feature left".

--

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 10.0
Next
From: Magnus Hagander
Date:
Subject: Re: 10.0