Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Josh berkus <josh(at)agliodbs(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Justin Clift <justin(at)postgresql(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Date: 2016-04-29 16:02:38
Message-ID: CANP8+j+Tr4Shovdacmf0-ijVGEFnpHbY3sUNMEQPJe2LQ8AK6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12 April 2016 at 20:25, Josh berkus <josh(at)agliodbs(dot)com> wrote:

> Here's the features I can imagine being worth major backwards
> compatibility breaks:
>
> 1. Fully pluggable storage with a clean API.
>
> 2. Total elimination of VACUUM or XID freezing
>
> 3. Fully transparent-to-the user MM replication/clustering or sharding.
>
> 4. Perfect partitioning (i.e. transparent to the user, supports keys &
> joins, supports expressions on partition key, etc.)
>
> 5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables
> without pg_upgrade or other modification).
>
> 6. Fully pluggable parser/executor with a good API
>
> That's pretty much it. I can't imagine anything else which would
> justify imposing a huge upgrade barrier on users. And, I'll point out,
> that in the above list:
>
> * nobody is currently working on anything in core except #4.
>
> * we don't *know* that any of the above items will require a backwards
> compatibility break.
>
> People keep talking about "we might want to break compatibility/file
> format one day". But nobody is working on anything which will and
> justifies it.
>

Of your list, I know 2ndQuadrant developers are working on 1, 3, 5.
6 has being discussed recently on list by other hackers.

I'm not really sure what 2 consists of; presumably this means "take the
pain away" rather than removal of MVCC, which is the root cause of those
secondary effects.

I don't think the current focus on manually intensive DDL partitioning is
the right way forwards. I did once; I don't now.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-04-29 16:05:08 Re: pg9.6 segfault using simple query (related to use fk for join estimates)
Previous Message Julien Rouhaud 2016-04-29 15:59:19 Re: pg9.6 segfault using simple query (related to use fk for join estimates)