Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallel Seq Scan
Date
Msg-id 7883.1422549609@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel Seq Scan  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Parallel Seq Scan
List pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
> On Tue, Jan 27, 2015 at 11:08 PM, Heikki Linnakangas <
> hlinnakangas@vmware.com> wrote:
>> OTOH, spreading the I/O across multiple files is not a good thing, if you
>> don't have a RAID setup like that. With a single spindle, you'll just
>> induce more seeks.
>> 
>> Perhaps the OS is smart enough to read in large-enough chunks that the
>> occasional seek doesn't hurt much. But then again, why isn't the OS smart
>> enough to read in large-enough chunks to take advantage of the RAID even
>> when you read just a single file?

> In my experience with RAID, it is smart enough to take advantage of that.
> If the raid controller detects a sequential access pattern read, it
> initiates a read ahead on each disk to pre-position the data it will need
> (or at least, the behavior I observe is as-if it did that).  But maybe if
> the sequential read is a bunch of "random" reads from different processes
> which just happen to add up to sequential, that confuses the algorithm?

If seqscan detection is being done at the level of the RAID controller,
I rather imagine that the controller would not know which process had
initiated which read anyway.  But if it's being done at the level of the
kernel, it's a whole nother thing, and I bet it *would* matter.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade and rsync
Next
From: Bruce Momjian
Date:
Subject: Re: TABLESAMPLE patch