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
|
Список | 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 по дате отправления: