| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, robertmhaas(at)gmail(dot)com |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PoC] Asynchronous execution again (which is not parallel) |
| Date: | 2016-01-21 10:09:19 |
| Message-ID: | 56A0AE4F.9000508@lab.ntt.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vitaly Burovoy | 2016-01-21 10:51:27 | Re: custom function for converting human readable sizes to bytes |
| Previous Message | Etsuro Fujita | 2016-01-21 09:55:01 | Re: Odd behavior in foreign table modification (Was: Re: Optimization for updating foreign tables in Postgres FDW) |