Re: Parallel Seq Scan vs kernel read ahead
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
Thomas Munro <thomas.munro@gmail.com>, Ranier Vilela <ranier.vf@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-06-22T04:54:22Z
Lists: pgsql-hackers
Attachments
- v2_patch_mbsec.png (image/png)
- v2_patch_millisec.png (image/png)
On Fri, 19 Jun 2020 at 14:10, David Rowley <dgrowleyml@gmail.com> wrote: > Here's a patch which caps the maximum chunk size to 131072. If > someone doubles the page size then that'll be 2GB instead of 1GB. I'm > not personally worried about that. > > I tested the performance on a Windows 10 laptop using the test case from [1] I also tested this an AMD machine running Ubuntu 20.04 on kernel version 5.4.0-37. I used the same 100GB table I mentioned in [1], but with the query "select * from t where a < 0;", which saves having to do any aggregate work. There seems to be quite a big win with Linux too. See the attached graphs. Both graphs are based on the same results, just the MB/sec one takes the query time in milliseconds and converts that into MB/sec for the 100 GB table. i.e. 100*1024/(<milliseconds> /1000) The machine is a 64core / 128 thread AMD machine (3990x) with a 1TB Samsung 970 Pro evo plus SSD, 64GB RAM > [1] https://www.postgresql.org/message-id/CAApHDvrfJfYH51_WY-iQqPw8yGR4fDoTxAQKqn%2BSa7NTKEVWtg%40mail.gmail.com
Commits
-
Allocate consecutive blocks during parallel seqscans
- 56788d2156fc 14.0 landed