Re: I'd like to discuss scaleout at PGCon - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: I'd like to discuss scaleout at PGCon
Date
Msg-id CANP8+jLhMfXYBVJ=o6x78PjGhmy-CUp29hdb8pQU_zCESAeBMg@mail.gmail.com
Whole thread Raw
In response to Re: I'd like to discuss scaleout at PGCon  (MauMau <maumau307@gmail.com>)
Responses Re: I'd like to discuss scaleout at PGCon
Re: I'd like to discuss scaleout at PGCon
List pgsql-hackers
On 1 June 2018 at 04:00, MauMau <maumau307@gmail.com> wrote:

> The SQL processor should be one layer, not two layers.

For OLTP, that would be best. But it would be restricted to
single-node requests, leaving you the problem of how you know ahead of
time whether an SQL statement was single node or not.

Using a central coordinator node allows us to hide the decision of
single-node/multi-node from the user which seems essential for general
SQL. If you are able to restrict the types of requests users make then
we can do direct access to partitions - so there is scope for a
single-node API, as Mongo provides.

Using a central coordinator also allows multi-node transaction
control, global deadlock detection etc..

And that is why both XL and "FDW approach" rely on a central coordinator.

FDWs alone are not enough. It is clear that some more tight coupling
is required to get things to work well. For example, supporting SQL
query plans that allow for redistribution of data for joins.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: I'd like to discuss scaleout at PGCon
Next
From: Steven Winfield
Date:
Subject: RE: FW: Possible optimisation: push down SORT and LIMIT nodes