On Wed, Feb 24, 2016 at 12:22:20PM +0300, Konstantin Knizhnik wrote: > Sorry, but based on this plan it is possible to make a conclusion > that there are only two possible cluster solutions for Postgres: > XC/XL and FDW-based. From my point of view there are much more > possible alternatives. > Our main idea with XTM (eXtensible Transaction Manager API) was to > make it possible to develop cluster solutions for Postgres as > extensions without patching code of Postgres core. And FDW is one of > the mechanism which makes it possible to reach this goal.
Yes, this is a good example of code reuse. > IMHO it will be hard to implement efficient execution of complex > OLAP queries (including cross-node joins and aggregation) within > FDW paradigm. It will be necessary to build distributed query > execution plan and coordinate it execution at cluster nodes. And > definitely we need specialized optimizer for distributed queries. > Right now solution of the problem are provided by XL and Greenplum, > but both are forks of Posrgres with a lot of changes in Postgres > core. The challenge is to provide the similar functionality, but at > extension level (using custom nodes, pluggable transaction manager, > ...). Agreed. > But, as you noticed, complex OLAP is just one of the scenarios and > this is not the only possible way of using clusters. In some cases > FDW-based sharding can be quite efficient. Or pg_shard approach > which also adds sharding at extension level and in some aspects is > more flexible than FDW-based solution. Not all scenarios require > global transaction manager. But if one need global consistency, then > XTM API allows to provide ACID for both approaches (and not only for > them). Yep. > We currently added to commitfest our XTM patch together with > postgres_fdw patch integrating timestamp-based DTM implementation in > postgres_fdw. It illustrates how global consistency canbe reached > for FDW-based sharding. > If this XTM patch will be committed, then in 9.6 we will have wide > flexibility to play with different distributed transaction managers. > And it can be used for many cluster solutions. > > IMHO it will be very useful to extend your classification of cluster > use cases, more precisely formulate demands in all cases, > investigate how them can be covered by existed cluster solutions > for Postgres and which niches are still vacant. We are currently > continue work on "multimaster" - some more convenient alternative to > hot-standby replication. Looks like PostgreSQL is missing some > product providing functionality similar to Oracle RAC or MySQL > Gallera. It is yet another direction of cluster development for > PostgreSQL. Let's be more open and flexible. Yes, I listed only the workloads I could think of. It would be helpful to list more workloads and start to decide what can be accomplished with each approach. I don't even know all the workloads supported by the sharding forks of Postgres. -- Bruce Momjian <br...@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 + -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers