Re: Parallel Seq Scan vs kernel read ahead
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-05-20T23:14:12Z
Lists: pgsql-hackers
Em qua., 20 de mai. de 2020 às 18:49, Thomas Munro <thomas.munro@gmail.com> escreveu: > On Wed, May 20, 2020 at 11:03 PM Ranier Vilela <ranier.vf@gmail.com> > wrote: > > Time: 47767,916 ms (00:47,768) > > Time: 32645,448 ms (00:32,645) > > Just to make sure kernel caching isn't helping here, maybe try making > the table 2x or 4x bigger? My test was on a virtual machine with only > 4GB RAM, so the table couldn't be entirely cached. > 4x bigger. Postgres defaults settings. postgres=# create table t as select generate_series(1, 800000000)::int i; SELECT 800000000 postgres=# \timing Timing is on. postgres=# set max_parallel_workers_per_gather = 0; SET Time: 8,622 ms postgres=# select count(*) from t; count ----------- 800000000 (1 row) Time: 227238,445 ms (03:47,238) postgres=# set max_parallel_workers_per_gather = 1; SET Time: 20,975 ms postgres=# select count(*) from t; count ----------- 800000000 (1 row) Time: 138027,351 ms (02:18,027) regards, Ranier Vilela
Commits
-
Allocate consecutive blocks during parallel seqscans
- 56788d2156fc 14.0 landed