Re: [HACKERS] asynchronous execution

At Mon, 11 Dec 2017 20:07:53 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20171211(dot)200753(dot)191768178(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> > The attached PoC patch theoretically has no impact on the normal
> > code paths and just brings gain in async cases.
>
> The parallel append just committed hit this and the attached are
> the rebased version to the current HEAD. The result of a concise
> performance test follows.
>
> patched(ms) unpatched(ms) gain(%)
> A: simple table scan : 3562.32 3444.81 -3.4
> B: local partitioning : 1451.25 1604.38 9.5
> C: single remote table : 8818.92 9297.76 5.1
> D: sharding (single con) : 5966.14 6646.73 10.2
> E: sharding (multi con) : 1802.25 6515.49 72.3
>
> > A and B are degradation checks, which are expected to show no
> > degradation. C is the gain only by postgres_fdw's command
> > presending on a remote table. D is the gain of sharding on a
> > connection. The number of partitions/shards is 4. E is the gain
> > using dedicate connection per shard.
>
> Test A is accelerated by parallel sequential scan. Introducing
> parallel append accelerates test B. Comparing A and B, I doubt
> that degradation is stably measurable at least my environment but
> I believe that there's no degradation theoreticaly. The test C to
> E still shows apparent gain.
> regards,

The patch conflicts with 3cac0ec. This is the rebased version.

--
Kyotaro Horiguchi
NTT Open Source Software Center