Re: Parallel Seq Scan vs kernel read ahead - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Parallel Seq Scan vs kernel read ahead
Date
Msg-id CA+hUKG+NcKUPi=wBS+d2-+yxC8vZJbPpi8qt8T0fjP1ULTdCTw@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan vs kernel read ahead  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Parallel Seq Scan vs kernel read ahead  (David Rowley <dgrowleyml@gmail.com>)
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [PATCH] Add support for choosing huge page size
Next
From: Li Japin
Date:
Subject: Re: Terminate the idle sessions