Re: I'd like to discuss scaleout at PGCon

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: I'd like to discuss scaleout at PGCon
Дата
Msg-id CANP8+jLhMfXYBVJ=o6x78PjGhmy-CUp29hdb8pQU_zCESAeBMg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: I'd like to discuss scaleout at PGCon  (MauMau <maumau307@gmail.com>)
Ответы Re: I'd like to discuss scaleout at PGCon  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Re: I'd like to discuss scaleout at PGCon  ("MauMau" <maumau307@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: I'd like to discuss scaleout at PGCon
Следующее
От: Steven Winfield
Дата:
Сообщение: RE: FW: Possible optimisation: push down SORT and LIMIT nodes