Re: Parallell Optimizer
От | Tatsuo Ishii |
---|---|
Тема | Re: Parallell Optimizer |
Дата | |
Msg-id | 20130612.080148.941243657043739777.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: Parallell Optimizer (Hannu Krosing <hannu@2ndQuadrant.com>) |
Ответы |
Re: Parallell Optimizer
Re: Parallell Optimizer Re: Parallell Optimizer |
Список | 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
В списке pgsql-hackers по дате отправления: