Re: Parallell Optimizer

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: hannu(at)2ndQuadrant(dot)com
Cc: simon(at)2ndQuadrant(dot)com, michael(dot)paquier(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, robertmhaas(at)gmail(dot)com, fred(at)nti(dot)ufop(dot)br, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parallell Optimizer
Date: 2013-06-11 23:01:48
Message-ID: 20130612.080148.941243657043739777.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> Please explain what you mean by the word "true" used here.
>> In another word, "eager replication".
> Do you mean something along these lines :
>
> "Most synchronous or eager replication solutions do conflict prevention,
> while asynchronous solutions have to do conflict resolution. For instance,
> if a record is changed on two nodes simultaneously, an eager replication
> system would detect the conflict before confirming the commit and abort
> one of the transactions. A lazy replication system would allow both
> transactions to commit and run a conflict resolution during
> resynchronization. "
>
> ?

No, I'm not talking about conflict resolution.

From http://www.cs.cmu.edu/~natassa/courses/15-823/F02/papers/replication.pdf:
----------------------------------------------
Eager or Lazy Replication?
Eager replication:
keep all replicas synchronized by updating all
replicas in a single transaction

Lazy replication:
asynchronously propagate replica updates to
other nodes after replicating transaction commits
----------------------------------------------

Parallel query execution needs to assume that each node synchronized
in a commit, otherwise the summary of each query result executed on
each node is meaningless.

> IMO it is possible to do this "easily" once BDR has reached the state
> where you
> can do streaming apply.
> That is, you replay actions on other hosts as they
> are logged, not after the transaction commits. Doing it this way you can
> wait
> any action to successfully complete a full circle before committing it
> in source.
>
> Currently main missing part in doing this is autonomous transactions.
> It can in theory be done by opening an extra backend for each incoming
> transaction but you will need really big number of backends and also you
> have extra overhead from interprocess communications.

Thanks for a thought about the conflict resolution in BDR.

BTW, if we seriously think about implementing the parallel query
execution, we need to find a way to distribute data among each node,
that requires partial copy of table. I thinl that would a big
challenge for WAL based replication.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2013-06-11 23:17:38 Re: Parallell Optimizer
Previous Message Andrew Dunstan 2013-06-11 22:58:05 Re: JSON and unicode surrogate pairs