The post shows a 3.5x performance improvement for requested 4-way parallelism, so that's a significant improvement right now! You might be surprised how many q

The post shows a 3.5x performance improvement for requested 4-way parallelism, so that's a significant improvement right now! You might be surprised how many queries are bound by memory bus bandwidth and CPU, rather than I/O ... but even I/O bound queries may benefit: Remember that postgres is a "demand-pull" system. A sequential scan node returns a single tuple at a time, whenever its parent node asks for a tuple. So there can be considerable time between requests for an actual disk block. Parallelizing the scan should result in more frequent requests to the disk controller, which could then have better opportunity to optimize reads - even for a single disk. Since most of the latency for spinning disks is seek time, having more outstanding block-read requests should help performance.