| From: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: using custom scan nodes to prototype parallel sequential scan |
| Date: | 2014-11-11 00:00:28 |
| Message-ID: | CAJrrPGfQDTm1OOp8xN5gOq7OSzOnhY1gv8KO5NA0ZOkr5cabRQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 11, 2014 at 10:21 AM, Andres Freund <andres(at)2ndquadrant(dot)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 feel this may play a major role
when the selectivity is more.
Regards,
Hari Babu
Fujitsu Australia
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2014-11-11 00:04:29 | Re: SSL information view |
| Previous Message | Peter Geoghegan | 2014-11-10 23:33:07 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |