At Mon, 11 Jul 2016 17:10:11 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in
<20160711.171011.133133724.horiguchi.kyotaro@lab.ntt.co.jp>
> > Two things:
> >
> > 1. That's not the scenario I'm talking about. I'm concerned about
> > making sure that query plans that don't use asynchronous execution
> > don't get slower.
>
> The first one donen't (select for t0) is that. It have any
> relation with asynchronous staff except the result_ready flag, a
> branch caused by it and calling ExecDispatchNode. The difference
> from the original is ExecProcNode uses ExecDispatchNode. Even
> ExecAsyncWaitForNode is not called.
>
> > 2. I have to believe that's a defect in your implementation rather
> > than something intrinsic, or maybe your test scenario is bad. It's
> > very hard - really impossible - to believe that all queries involving
> > FDW pushdown are locally CPU-bound.
>
> Sorry for hard-to-read result but the problem is not in a query
> involving FDW, but a query on a local table (but runs parallel
> seqscan). The reason of the difference for the tests involving
> FDW should be local scans on the remote side.
>
> Just reverting ExecProcNode and other related part doesn't change
> the situation. I proceed the confirmation reverting part by
> part.
Uggg. I had no difference even after finally bumped into master.
What is more strange, a binary built from what should be the same
"master" but extended by "git archive | tar" finishes the query
(select sum(a) from t0) in a half time to the master in my git
reposiotrty with -O2. In short, the patch doesn't seem to be the
cause of the difference.
I should investigate the difference between them, or begin again
with a clean environment..
Anyway I need some time to cool down..
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center