Re: asynchronous execution
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: asynchronous execution |
Дата | |
Msg-id | 20161025.182150.230901487.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: asynchronous execution (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: asynchronous execution
|
Список | pgsql-hackers |
This is the rebased version on the current master(-0004), and added resowner stuff (0005) and unlikely(0006). At Tue, 18 Oct 2016 10:30:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in <20161018.103051.30820907.horiguchi.kyotaro@lab.ntt.co.jp> > > > - Errors in the executor can leak the WaitEventSet. Probably we need > > > to modify ResourceOwners to be able to own WaitEventSets. > > WaitEventSet itself is not leaked but epoll-fd should be closed > at failure. This seems doable with TRY-CATCHing in > ExecAsyncEventLoop. (not yet) Haha, that's a silly talk. The wait event can continue to live when timeout and any error can happen on the way after the that. I added an entry for wait event set to resource owner and hang ones created in ExecAsyncEventWait to TopTransactionResourceOwner. Currently WaitLatchOrSocket doesn't do so not to change the current behavior. WaitEventSet doesn't have usable identifier for resowner.c so currently I use the address(pointer value) for the purpose. The patch 0005 does that. > I measured performance and had the following result. > > t0 - SELECT sum(a) FROM <local single table>; > pl - SELECT sum(a) FROM <4 local children>; > pf0 - SELECT sum(a) FROM <4 foreign children on single connection>; > pf1 - SELECT sum(a) FROM <4 foreign children on dedicate connections>; > > The result is written as "time<ms> (std dev <ms>)" > > sync > t0: 3820.33 ( 1.88) > pl: 1608.59 ( 12.06) > pf0: 7928.29 ( 46.58) > pf1: 8023.16 ( 26.43) > > async > t0: 3806.31 ( 4.49) 0.4% faster (should be error) > pl: 1629.17 ( 0.29) 1.3% slower > pf0: 6447.07 ( 25.19) 18.7% faster > pf1: 1876.80 ( 47.13) 76.6% faster > > t0 is not affected since the ExecProcNode stuff has gone. > > pl is getting a bit slower. (almost the same to simple seqscan of > the previous patch) This should be a misprediction penalty. Using likely macro for ExecAppend, and it seems to have shaken off the degradation. sync t0: 3919.49 ( 5.95) pl: 1637.95 ( 0.75)pf0: 8304.20 ( 43.94)pf1: 8222.09 ( 28.20) async t0: 3885.84 ( 40.20) 0.86% faster (should be error but stable on my env..) pl: 1617.20 ( 3.51) 1.26% faster (ditto)pf0:6680.95 (478.72) 19.5% fasterpf1: 1886.87 ( 36.25) 77.1% faster regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: