Re: asynchronous and vectorized execution
От | Robert Haas |
---|---|
Тема | Re: asynchronous and vectorized execution |
Дата | |
Msg-id | CA+TgmoaF2yR0uQNFBahbo19spJ=40ee7qQWb4voo3mpx_-A8yA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: asynchronous and vectorized execution (Amit Khandekar <amitdkhan.pg@gmail.com>) |
Список | pgsql-hackers |
On Fri, Sep 23, 2016 at 8:45 AM, Amit Khandekar <amitdkhan.pg@gmail.com> wrote: > For e.g., in the above plan which you specified, suppose : > 1. Hash Join has called ExecProcNode() for the child foreign scan b, and so > is > waiting in ExecAsyncWaitForNode(foreign_scan_on_b). > 2. The event wait list already has foreign scan on a that is on a different > subtree. > 3. This foreign scan a happens to be ready, so in > ExecAsyncWaitForNode (), ExecDispatchNode(foreign_scan_a) is called, > which returns with result_ready. > 4. Since it returns result_ready, it's parent node is now inserted in the > callbacks array, and so it's parent (Append) is executed. > 5. But, this Append planstate is already in the middle of executing Hash > join, and is waiting for HashJoin. Ah, yeah, something like that could happen. I've spent much of this week working on a new design for this feature which I think will avoid this problem. It doesn't work yet - in fact I can't even really test it yet. But I'll post what I've got by the end of the day today so that anyone who is interested can look at it and critique. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: