Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Parallel Seq Scan
Дата
Msg-id 7883.1422549609@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade and rsync
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: TABLESAMPLE patch