On Mon, Mar 13, 2017 at 9:28 PM, Amit Langote <langote_amit...@lab.ntt.co.jp > wrote:
> On 2017/03/14 10:08, Corey Huinker wrote: > >> I don't think the plan itself will change as a result of applying this > >> patch. You might however be able to observe some performance > improvement. > > > > I could see no performance improvement, even with 16 separate queries > > combined with UNION ALL. Query performance was always with +/- 10% of a > 9.6 > > instance given the same script. I must be missing something. > > Hmm, maybe I'm missing something too. > > Anyway, here is an older message on this thread from Horiguchi-san where > he shared some of the test cases that this patch improves performance for: > > https://www.postgresql.org/message-id/20161018.103051. > 30820907.horiguchi.kyotaro%40lab.ntt.co.jp > > From that message: > > <quote> > 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 > </quote> > > IIUC, pf0 and pf1 is the same test case (all 4 foreign tables target the > same server) measured with different implementations of the patch. > > Thanks, > Amit > I reworked the test such that all of the foreign tables inherit from the same parent table, and if you query that you do get async execution. But It doesn't work when just stringing together those foreign tables with UNION ALLs. I don't know how to proceed with this review if that was a goal of the patch.
