Re: Parallell Optimizer

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Parallell Optimizer
Дата
Msg-id CAB7nPqRnw9NNb_i=CWL_P_9FkTD=jwXwT_C4bROK4oy9NA7NWA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallell Optimizer  (Tatsuo Ishii <ishii@postgresql.org>)
Ответы Re: Parallell Optimizer  (Tatsuo Ishii <ishii@postgresql.org>)
Список pgsql-hackers



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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Parallell Optimizer
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Hard limit on WAL space used (because PANIC sucks)