Re: Parallel Seq Scan vs kernel read ahead
От | Thomas Munro |
---|---|
Тема | Re: Parallel Seq Scan vs kernel read ahead |
Дата | |
Msg-id | CA+hUKG+NcKUPi=wBS+d2-+yxC8vZJbPpi8qt8T0fjP1ULTdCTw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan vs kernel read ahead (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: Parallel Seq Scan vs kernel read ahead
|
Список | pgsql-hackers |
On Wed, Jun 10, 2020 at 5:06 PM David Rowley <dgrowleyml@gmail.com> wrote: > I repeated this test on an up-to-date Windows 10 machine to see if the > later kernel is any better at the readahead. > > Results for the same test are: > > Master: > > max_parallel_workers_per_gather = 0: Time: 148481.244 ms (02:28.481) > (706.2MB/sec) > max_parallel_workers_per_gather = 1: Time: 327556.121 ms (05:27.556) > (320.1MB/sec) > max_parallel_workers_per_gather = 2: Time: 329055.530 ms (05:29.056) > (318.6MB/sec) > > Patched: > > max_parallel_workers_per_gather = 0: Time: 141363.991 ms (02:21.364) > (741.7MB/sec) > max_parallel_workers_per_gather = 1: Time: 144982.202 ms (02:24.982) > (723.2MB/sec) > max_parallel_workers_per_gather = 2: Time: 143355.656 ms (02:23.356) > (731.4MB/sec) Thanks! I also heard from Andres that he likes this patch with his AIO prototype, because of the way request merging works. So it seems like there are several reasons to want it. But ... where should we get the maximum step size from? A GUC?
В списке pgsql-hackers по дате отправления: