Re: Wait for parallel workers to attach

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Wait for parallel workers to attach
Дата
Msg-id CA+TgmoYUZWD12cNXhAunoDBWeU4BfM-U5GjrZVkngLUoqUBHyA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Wait for parallel workers to attach  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Wait for parallel workers to attach
Список pgsql-hackers
On Wed, Jan 31, 2018 at 3:57 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> * There might be some opportunity to share some of the new code with
>> the code recently committed to WaitForParallelWorkersToFinish(). For
>> one thing, the logic in this block could be refactored into a
>> dedicated function that is called by both
>> WaitForParallelWorkersToAttach() and WaitForParallelWorkersToFinish():
>
> I had thought about this earlier but left it as the common code was
> too less, however as you have pointed out, I had extracted the common
> code into a separate function.

I like it better the other way, so I've changed it back in the
attached version, which also works over the comments fairly heavily.

> I think we should not touch anything related to Gather (merge) as they
> don't need it for the purpose of correctness.  However, we might want
> to improve them by using this new API at a certain point if the need
> arises.  I guess we can use this API to detect failures early.

I added a comment in this version explaining why it works, so that we
don't forget (again).  If we decide to change it in the future then we
can remove or update the comment.

Another thing I did was known_started_workers ->
known_attached_workers, which I think is more precisely correct.

Please let me know your thoughts about this version.  If it looks OK,
I'll commit it.

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

Вложения

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: JIT compiling with LLVM v9.0
Следующее
От: Yugo Nagata
Дата:
Сообщение: CURRENT OF causes an error when IndexOnlyScan is used