Re: The plan for FDW-based sharding

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: The plan for FDW-based sharding
Date: 2016-02-24 16:02:21
Message-ID: 20160224160221.GA403874@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
> On Wed, Feb 24, 2016 at 01:08:29AM +0000, Simon Riggs wrote:

> > It's never been our policy to try to include major projects in single code
> > drops. Any move of XL/XC code into PostgreSQL core would need to be done piece
> > by piece across many releases. XL is definitely too big for the elephant to eat
> > in one mouthful.
>
> Is there any plan to move the XL/XC code into Postgres? If so, I have
> not heard of it. I thought everyone agreed it was too much code change,
> which is why it is a separate code tree. Is that incorrect?

Yes, I think that's incorrect.

What was said, as I understood it, is that Postgres-XL is too big to
merge in a single commit -- just like merging BDR would have been.
Indulge me while I make a parallel with BDR for a bit.
2ndQuadrant never pushed for merging BDR in a single commit; what was
done was to split it, and propose individual pieces for commit. Many of
these pieces are now already committed (event triggers, background
workers, logical decoding, replication slots, and many others). The
"BDR patch" is now much smaller, and it's quite possible that we will
see it merged someday. Will it be different from what it was when the
BDR project started, all those years ago? You bet. Having the
prototype BDR initially was what allowed the whole plan to make sense,
because it showed that the pieces interacted in the right ways to make
it work as a whole.

(I'm not saying 2ndQuadrant is so wise to do things this way. I'm
pretty sure you can see the same thing in parallel query development,
for instance.)

In the same way, Postgres-XL is far too big to merge in a single commit.
But that doesn't mean it will never be merged. What is more likely to
happen instead is that some pieces of it are going to be submitted
separately for consideration. It is a slow process, but progress is
real and tangible. We know this process will yield a useful outcome,
because the architecture has already proven by the existance of
Postgres-XL itself. It's the prototype that proves the overall design,
even if the pieces change shape during the process. (Really, it's way
more than merely a prototype at this point because of how long it has
matured.)

In contrast, we don't have a prototype for FDW-based sharding; as you
admitted, there is no actual plan, other than "let's push FDWs in this
direction and hope that sharding will emerge". We don't really know
what pieces we need or how will they interact with each other; we have a
vague idea of a direction but there's no clear path forward. As the
saying goes, if you don't know where you're going, you will probably end
up somewhere else.

--
Álvaro Herrera 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 Bruce Momjian 2016-02-24 16:13:07 Re: The plan for FDW-based sharding
Previous Message Bruce Momjian 2016-02-24 15:40:05 Re: The plan for FDW-based sharding