Re: [HACKERS] Parallel Append implementation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Parallel Append implementation
Дата
Msg-id CA+TgmoZ0gorCtarfby=a+9LAdp1bSMigH6vZjmcmnqcdcxxdsg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Parallel Append implementation  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] Parallel Append implementation  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, Oct 5, 2017 at 6:29 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> Okay, but can't we try to pick the cheapest partial path for master
> backend and maybe master backend can try to work on a partial path
> which is already picked up by some worker.

Well, the master backend is typically going to be the first process to
arrive at the Parallel Append because it's already running, whereas
the workers have to start.  So in the case that really matters, no
paths will have been picked yet.  Later on, we could have the master
try to choose a path on which some other worker is already working,
but I really doubt that's optimal.  Either the workers are generating
a lot of tuples (in which case the leader probably won't do much work
on any path because it will be busy reading tuples) or they are
generating only a few tuples (in which case the leader is probably
better off working on an a path not yet chosen, to reduce contention).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] cache lookup errors for missing replication origins
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Comment typo