At Mon, 11 Jul 2016 17:10:11 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20160711.171011.133133724.horiguchi.kyot...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
