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
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 |