Re: 9.6 -> 10.0 - Mailing list pgsql-advocacy

On Mon, Apr 11, 2016 at 11:13:57AM +0300, Oleg Bartunov wrote:
> On Mar 22, 2016 9:03 PM, "Josh berkus" <josh@agliodbs.com> wrote:
> >
> > On 03/22/2016 10:52 AM, Peter Geoghegan wrote:
> > > On Tue, Mar 22, 2016 at 10:41 AM, Josh berkus <josh@agliodbs.com> wrote:
> > >> It's important to remember that PR strategy and engineering truth have
> > >> only a passing acquaintance.  While we don't want to promote vaporware,
> > >> we do sometimes soft-pedal our own features to our project's detriment.
> > >> In the current atomosphere of VC-funded hype, we'd do a bit better to
> > >> trumpet our accomplishements early and often.
> > >
> > > I see what you mean.
> > >
> > > The question must be asked: What feature *would* meet that "major
> > > version bump" standard? If it's not extensive parallelism, then I
> > > don't know what else it could be.
> >
> > Well, if we had pglogical AND parallel, I would be pushing hard for
> > 10.0.  As it is, I was going to wait to see what else gets in.
> >
> > As it is, we have parallel and we have all of the BDR dependancies
> > merged in, no?  That still seems like a new era for PostgreSQL; I think
> > we can expect the next few releases to be all about (a) parallelizing
> > more things and (b) building out clustering stuff.
> >
> > One thing we don't much talk about is that we hit an inflection point
> > somewhere in the 9.X series, as demonstrated by CitusDB: it is now as
> > easy to build out your "Postgres Fork" by using our APIs and hooks as it
> > is by forking the project.  That's going to make a big difference for us
> > in the long run, possibly bigger than any individual feature.
>
> Well, API is enough to build non-transactional distributed databases. We
> proposed pluggable TM to go further. Hope  it will get more attention at
> pgcon.

I'd love to see the more progress on transaction management,
especially for distributed cases.

> BTW, what's about unforking pipelinedb ? Is't possible with our API and
> hooks ?

So long as what's in PipelineDB can be used in a useful sense without
patching its IP into core, this is feasible.

There are much larger issues around getting a startup essentially to
surrender its IP if patches are required in that sense.  Even assuming
that their investors and counsel would agree to do it, there are still
large, architectural issues.  As a rule, what's great in addressing a
niche market is usually terrible when building public infrastructure,
which is what PostgreSQL is about.  I agree we need to get streaming
capabilities, but I'm far from sure that getting them from a
proprietary project would actually be a shorter route to them than
building them ourselves.

> There is a big demand from russian  companies to Postgres and we are
> in difficult situation. Small steps forward is good, but it looks
> like we need hard thinking about our roadmap.

What situation in particular?  Is Oracle making moves to make using
PostgreSQL legally difficult?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate