Re: asynchronous execution - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: asynchronous execution
Date
Msg-id 20160929.153039.51784306.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: asynchronous execution  (Amit Khandekar <amitdkhan.pg@gmail.com>)
List pgsql-hackers
Hello, thank you for the comment.

At Wed, 28 Sep 2016 10:00:08 +0530, Amit Khandekar <amitdkhan.pg@gmail.com> wrote in
<CAJ3gD9fRmEhUoBMnNN8K_QrHZf7m4rmOHTFDj492oeLZff8o=w@mail.gmail.com>
> On 24 September 2016 at 06:39, Robert Haas <robertmhaas@gmail.com> wrote:
> > Since Kyotaro Horiguchi found that my previous design had a
> > system-wide performance impact due to the ExecProcNode changes, I
> > decided to take a different approach here: I created an async
> > infrastructure where both the requestor and the requestee have to be
> > specifically modified to support parallelism, and then modified Append
> > and ForeignScan to cooperate using the new interface.  Hopefully that
> > means that anything other than those two nodes will suffer no
> > performance impact.  Of course, it might have other problems....
> 
> I see that the reason why you re-designed the asynchronous execution
> implementation is because the earlier implementation showed
> performance degradation in local sequential and local parallel scans.
> But I checked that the ExecProcNode() changes were not that
> significant as to cause the degradation.

The basic thought is that we don't allow degradation of as small
as around one percent for simple cases in exchange for this
feature (or similar ones).

Very simple case of SeqScan runs through a very short path, on
where prediction failure penalties of CPU by few branches results
in visible impact. I avoided that by using likely/unlikly but
more fundamental measure is preferable.

> It will not call ExecAsyncWaitForNode() unless that node
> supports asynchronism.

That's true, but it takes a certain amount of CPU cycle to decide
call it or not. The small bit of time is the issue in focus now.

> Do you feel there is anywhere else in
> the implementation that is really causing this degrade ? That
> previous implementation has some issues, but they seemed
> solvable. We could resolve the plan state recursion issue by
> explicitly making sure the same plan state does not get called
> again while it is already executing.


regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: Sample configuration files
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: IF (NOT) EXISTS in psql-completion