Re: asynchronous and vectorized execution

Поиск
Список
Период
Сортировка
От Amit Khandekar
Тема Re: asynchronous and vectorized execution
Дата
Msg-id CAJ3gD9ek4Y4SGTSuc_pzkGYwLMbrc9QOM7m1D8bj99JNW16o0g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: asynchronous and vectorized execution  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: asynchronous and vectorized execution  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
Дерево обсуждения


On 21 July 2016 at 15:20, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote:

After some consideration, I found that ExecAsyncWaitForNode
cannot be reentrant because it means that the control goes into
async-unaware nodes while having not-ready nodes, that is
inconsistent state. To inhibit such reentering, I allocated node
identifiers in depth-first order so that ascendant-descendant
relationship can be checked (nested-set model) in simple way and
call ExecAsyncConfigureWait only for the descendant nodes of the
parameter planstate.


We have estate->waiting_nodes containing a mix of async-aware and non-async-aware nodes. I was thinking, an asynchrony tree would have only async-aware nodes, with possible multiple asynchrony sub-trees in a tree. Somehow, if we restrict the bubbling up of events only upto the root of the asynchrony subtree, do you think we can simplify some of the complexities ? For e.g. ExecAsyncWaitForNode() has become a bit complex seemingly because it has to handle non-async-nodes also, and that's the reason I believe you have introduced modes such as ASYNCCONF_FORCE_ADD.
 
regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Broken order-of-operations in parallel query latch manipulation
Следующее
От: Haribabu Kommi
Дата:
Сообщение: Re: System load consideration before spawning parallel workers