On Thu, 21 May 2020 at 17:06, David Rowley <dgrowle...@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
