Re: Parallell Optimizer - Mailing list 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 allreplicas in a single
transaction
Lazy replication:asynchronously propagate replica updates toother 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