Re: [PoC] Asynchronous execution again (which is not parallel)
От | Amit Langote |
---|---|
Тема | Re: [PoC] Asynchronous execution again (which is not parallel) |
Дата | |
Msg-id | 56A0AE4F.9000508@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [PoC] Asynchronous execution again (which is not parallel) (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [PoC] Asynchronous execution again (which is not
parallel)
|
Список | pgsql-hackers |
Hi! On 2016/01/21 18:26, Kyotaro HORIGUCHI wrote: >>> Then, suppose we add a function bool ExecStartAsync(PlanState *target, >>> ExecCallback callback, PlanState *cb_planstate, void *cb_context). >>> For non-async-aware plan nodes, this just returns false. async-aware >>> plan nodes should initiate some work, register some callbacks, and >>> return. The callback that get registered should arrange in turn to >>> register the callback passed as an argument when a tuple becomes >>> available, passing the planstate and context provided by >>> ExecStartAsync's caller, plus the TupleTableSlot containing the tuple. >> >> Although I don't imagine clearly about the case of >> async-aware-nodes under non-aware-nodes, it seems to have a high >> affinity with (true) parallel execution framework. > > The ExecStartAsync is similar to ExecStartNode of my old > patch. One of the most annoying things of that is that it needs > to walk down to their descendents and in turn it needs garbageous > corresponding additional codes for all type of nodes which can > have children. Unless I am missing something, I wonder if this is where planstate_tree_walker() introduced by commit 8dd401aa is useful. For example, I see that it's used in ExecShutdownNode() in a manner that looks interesting for this discussion. Thanks, Amit
В списке pgsql-hackers по дате отправления: