Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Gavin Flower
Тема Re: Parallel Seq Scan
Дата
Msg-id 55944AD7.7020003@archidevsys.co.nz
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Parallel Seq Scan  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: 9.6 commitfest schedule
Следующее
От: Tom Lane
Дата:
Сообщение: Re: NULL passed as an argument to memcmp() in parse_func.c