> On Tue, Jun 11, 2013 at 9:45 AM, Tatsuo Ishii <ishii@postgresql.org> wrote:
>
>> > On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs <simon@2ndquadrant.com>
>> wrote:
>> >
>> >> On 7 June 2013 20:23, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >>
>> >> > As for other databases, I suspect that ones that have parallel
>> execution
>> >> > are probably doing it with a thread model not a process model.
>> >>
>> >> Separate processes are more common because it covers the general case
>> >> where query execution is spread across multiple nodes. Threads don't
>> >> work across nodes and parallel queries predate (working) threading
>> >> models.
>> >>
>> > Indeed. Parallelism based on processes would be more convenient for
>> > master-master
>> > type of applications. Even if no master-master feature is implemented
>> > directly in core,
>> > at least a parallelism infrastructure based on processes could be used
>> for
>> > this purpose.
>>
>> As long as "true" synchronous replication is not implemented in core,
>> I am not sure there's a value for parallel execution spreading across
>> multile nodes because of the delay of data update propagation.
>>
> True, but we cannot drop the possibility to have such features in the future
> either, so a process-based model is safer regarding the possible range of
> features and applications we could gain with.
I wonder why "true" synchronous replication nor "eager replication"
are not in the developer TODO list. If we want them in the future,
they should be on it.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp