Re: [HACKERS] asynchronous execution
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: [HACKERS] asynchronous execution |
Дата | |
Msg-id | 20170321.121612.253115026.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] asynchronous execution (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: asynchronous execution
|
Список | pgsql-hackers |
Hello. This is the final report in this CF period. At Fri, 17 Mar 2017 17:35:05 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in <20170317.173505.152063931.horiguchi.kyotaro@lab.ntt.co.jp> > Async-capable plan is generated in planner. An Append contains at > least one async-capable child becomes async-aware Append. So the > async feature should be effective also for the UNION ALL case. > > The following will work faster than unpatched version.I > > SELECT sum(a) FROM (SELECT a FROM ft10 UNION ALL SELECT a FROM ft20 UNION ALL SELECT a FROM ft30 UNION ALL SELECT a FROMft40) as ft; > > I'll measure the performance for the case next week. I found that the following query works as the same as partitioned table. SELECT sum(a) FROM (SELECT a FROM ft10 UNION ALL SELECT a FROM ft20 UNION ALL SELECT a FROM ft30 UNION ALL SELECT a FROMft40 UNION ALL *SELECT a FROM ONLY pf0*) as ft; So, the difference comes from the additional async-uncapable child (faster if contains any). In both cases, Append node runs children asynchronously but slightly differently when all async-capable children are busy. I'll continue working on this from this point aiming to the next commit fest. Thank you for valuable feedback. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: