On Wed, Feb 24, 2016 at 09:34:37AM -0500, Bruce Momjian wrote:
> > I have nothing against particular FDW advances. However, it's unclear for me
> > that FDW should be the only sharding approach.
> > It's unproven that FDW can do work that Postgres XC/XL does. With FDW we can
> > have some low-hanging fruits. That's good.
> > But it's unclear we can have high-hanging fruits (like data redistribution)
> > with FDW approach. And if we can it's unclear that it would be easier than with
> > other approaches.
> > Just let's don't call this community chosen plan for implementing sharding.
> > Until we have full picture we can't select one way and reject others.
>
> I agree. I think the FDW approach is the only existing approach for
> built-in sharding though. The forks of Postgres doing sharding are,
> just that, forks and just Postgres community ecosystem projects. (Yes,
> they are open source.) If the forks were community-chosen plans we
> hopefully would not have 5+ of them. If FDW works, it has the potential
> to be the community-chosen plan, at least for the workloads it supports,
> because it is built into community Postgres in a way the others cannot.
>
> That doesn't mean the forks go away, but rather their value is in doing
> things the FDW approach can't, but there are a lot of "if's" in there.
Actually, this seems similar to how we handled replication. For years
we had multiple external replication solutions. When we implemented
streaming replication, we knew it would become the default for workloads
it supports. The external solutions didn't go away, but their value was
in handling workloads that streaming replication didn't support.
I think the only difference is that we knew streaming replication would
have this effect before we implemented it, while with FDW-based
sharding, we don't know.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
