Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Gavin Flower
Subject Re: Parallel Seq Scan
Date
Msg-id 55944AD7.7020003@archidevsys.co.nz
Whole thread Raw
In response to Re: Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 01/07/15 17:37, Amit Kapila wrote:
> On Tue, Jun 30, 2015 at 4:00 AM, Jeff Davis <pgsql@j-davis.com 
> <mailto:pgsql@j-davis.com>> wrote:
> >
> > [Jumping in without catching up on entire thread.
>
[...]
> .
>
> > 2. Where is the speedup coming from? How much of it is CPU and IO
> > overlapping (i.e. not leaving disk or CPU idle while the other is
> > working), and how much from the CPU parallelism? I know this is
> > difficult to answer rigorously, but it would be nice to have some
> > breakdown even if for a specific machine.
> >
>
> Yes, you are right and we have done quite some testing (on the hardware
> available) with this patch (with different approaches) to see how much
> difference it creates for IO and CPU, with respect to IO we have found
> that it doesn't help much [1], though it helps when the data is cached
> and there are really good benefits in terms of CPU [2].
>
[...]

I assume your answer refers to a table on one spindle of spinning rust.


QUESTIONS:
1. what about I/O using an SSD?
2. what if the table is in a RAID array (of various types), would   having the table spread over multiple spindles
help?



Cheers,
Gavin



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: 9.6 commitfest schedule
Next
From: Tom Lane
Date:
Subject: Re: NULL passed as an argument to memcmp() in parse_func.c