Re: Horizontal scalability/sharding - Mailing list pgsql-hackers

From Oleg Bartunov
Subject Re: Horizontal scalability/sharding
Date
Msg-id CAF4Au4yLJC1eeyVdeH-hd=GWBpEywjStGx9rTCTYGHvDo8ZKqw@mail.gmail.com
Whole thread Raw
In response to Re: Horizontal scalability/sharding  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Horizontal scalability/sharding  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List pgsql-hackers


On Tue, Sep 1, 2015 at 7:08 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Sep 1, 2015 at 12:00 AM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
> My worry is that if we start implementing them again from scratch, it will
> take a few years before we get them in a usable state. What XC/XL lacked is
> probably a Robert Haas or a Tom Lane who could look at the work and suggest
> major edits. If that had happened, the quality of the product could have
> been much better today. I don't mean to derate the developers who worked on
> XC/XL, but there is no harm in accepting that if someone with a much better
> understanding of the whole system was part of the team, that would have
> positively impacted the project. Is that an angle worth exploring? Does it
> make sense to commit some more resources to say XC or XL and try to improve
> the quality of the product even further? To be honest, XL is in far far
> better shape (haven't really tried XC in a while) and some more QA/polishing
> can make it production ready much sooner.

From my point of view, and EnterpriseDB's point of view, anything that
doesn't go into the core PostgreSQL distribution isn't really getting
us where we need to be.  If there's code in XL that would be valuable
to merge into core PostgreSQL, then let's do it.  If the code cannot
be used but there are lessons we can learn that will make what does go
into core PostgreSQL better, let's learn them.  However, I don't think
it's serving anybody very well that we have the XC fork, and multiple
forks of the XC fork, floating around out there and people are working
on those instead of working on core PostgreSQL.  The reality is that
we don't have enough brainpower to spread it across 2 or 3 or 4 or 5
different projects and have all of them be good.  The reality is,
also, that horizontal scalability isn't an optional feature.  There
was a point in time at which the PostgreSQL project's official policy
on replication was that it did not belong in core.  That was a bad
policy; thankfully, it was reversed, and the result was Hot Standby
and Streaming Replication, incredibly important technologies without
which we would not be where we are today. Horizontal scalability is
just as essential.

Agree with you, Robert.

One lesson from XL we got is that we need testing framework for cluster, so any cluster project should at least pass functional and performance testing. XL was very easy to break and I'm wondering how many corner cases still exists. We tried several other approaches and while reading the papers was a fun, in practice we found many devil details, which made the paper be just a paper. 

 

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: creating extension including dependencies
Next
From: Andres Freund
Date:
Subject: Re: Improving test coverage of extensions with pg_dump