Re: Horizontal scalability/sharding

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Mason S <masonlists(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Horizontal scalability/sharding
Date: 2015-09-02 06:05:22
Message-ID: 55E691A2.7000706@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015/09/02 14:28, Amit Langote wrote:
> On 2015-09-02 PM 01:28, Amit Kapila wrote:
>>> On Tue, Sep 1, 2015 at 9:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> I'm not averse to making the "connect to the remote nodes" part of
>>>> this solution use something other than the FDW infrastructure at some
>>>> point in time if somebody's prepared to build something better. On
>>>> the other hand, I think it's extremely clear that the FDW
>>>> infrastructure has a large amount of potential upon which we have
>>>> thoroughly failed to capitalize. Patches have already been written
>>>> for UPDATE/DELETE pushdown and for join pushdown.

>> Will pushing down writes (Update/Delete) sufficient to maintain sane locking
>> behaviour and deadlock detection that can occur during writes on multiple
>> shards? For example it could easily be the case where a single Update
>> statement could effect multiple shards and cause deadlock due to waits
>> across the nodes. Now unless we have some distributed lock manager or
>> some other way to know the information of locks that happens across
>> shards, it could be difficult to detect deadlocks.

> I wonder if Ashutosh's atomic foreign transactions patch would address any
> issues inherent in such cases...

The UPDATE/DELETE pushdown, which I've proposed, would ensure the sane
behaviour for inherited UPDATEs/DELETEs, as existing non-pushed-down
UPDATE/DELETE does, because inheritance_planner guarantees that all
backends lock inheritance children in the same order to avoid needless
deadlocks.

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-09-02 06:13:03 Re: Fwd: Core dump with nested CREATE TEMP TABLE
Previous Message Stefan Kaltenbrunner 2015-09-02 05:58:26 Re: Proposing COPY .. WITH PERMISSIVE