Re: Parallel Seq Scan vs kernel read ahead

On Thu, 21 May 2020 at 17:06, David Rowley <dgrowleyml@gmail.com> wrote:
> create table t (a int, b text);
> -- create a table of 100GB in size.
> insert into t select x,md5(x::text) from
> generate_series(1,1000000*1572.7381809)x; -- took 1 hr 18 mins
> vacuum freeze t;
>
> query = select count(*) from t;
> Disk = Samsung SSD 850 EVO mSATA 1TB.
>
> Master:
> workers = 0 : Time: 269104.281 ms (04:29.104)  380MB/s
> workers = 1 : Time: 741183.646 ms (12:21.184)  138MB/s
> workers = 2 : Time: 656963.754 ms (10:56.964)  155MB/s
>
> Patched:
>
> workers = 0 : Should be the same as before as the code for this didn't change.
> workers = 1 : Time: 300299.364 ms (05:00.299) 340MB/s
> workers = 2 : Time: 270213.726 ms (04:30.214) 379MB/s
>
> (A better query would likely have been just: SELECT * FROM t WHERE a =
> 1; but I'd run the test by the time I thought of that.)
>
> So, this shows that Windows, at least 8.1, does suffer from this too.

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)

David