Re: using custom scan nodes to prototype parallel sequential scan - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: using custom scan nodes to prototype parallel sequential scan
Date
Msg-id CAA4eK1JRht63WiVW_c7VoZAc5Pd7mqO4+d2drk1q8SW-k4qDNA@mail.gmail.com
Whole thread Raw
In response to Re: using custom scan nodes to prototype parallel sequential scan  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: using custom scan nodes to prototype parallel sequential scan  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
On Tue, Nov 11, 2014 at 5:30 AM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
>
> On Tue, Nov 11, 2014 at 10:21 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-11-10 10:57:16 -0500, Robert Haas wrote:
> >> Does parallelism help at all?
> >
> > I'm pretty damn sure. We can't even make a mildly powerfull storage
> > fully busy right now. Heck, I can't make my workstation's storage with a
> > raid 10 out of four spinning disks fully busy.
> >
> > I think some of that benefit also could be reaped by being better at
> > hinting the OS...
>
> Yes, it definitely helps but not only limited to IO bound operations.
> It gives a good gain for the queries having CPU intensive where conditions.
>
> One more point we may need to consider, is there any overhead in passing
> the data row from workers to backend?

I am not sure if that overhead will be too much visible if we improve the
use of I/O subsystem by making parallel tasks working on it. However
another idea here could be that instead of passing tuple data, we just
pass tuple id, but in that case we have to retain the pin on the buffer
that contains tuple untill master backend reads from it that might have
it's own kind of problems.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: mariem
Date:
Subject: Re: Convert query plan to sql query
Next
From: Haribabu Kommi
Date:
Subject: Re: using custom scan nodes to prototype parallel sequential scan