The bitmap heap scan can benefit quite a bit from effective_io_concurrency on RAID system (and to some extent even on single spindle systems)
However, the planner isn't aware of this. So you have to just be lucky to have it choose the bitmap heap scan instead of something else that can't benefit from effective_io_concurrency. As far as I can tell, the only thing that drives the bitmap heap scan down in cost is the estimation that you will end up getting multiple tuples from the same block. And because of the fuzzy in compare_path_costs_fuzzily, the estimate has to be 1% of redundant blocks before the bitmap scan will be considered, and I think the benefits of effective_io_concurrency can kick in well before that on very large data sets. Also, if there some correlation in the table, then the situation is worse because the index scan lowers its block-read estimates based on the correlation, while the bitmap scan does not lower its estimate. I haven't witnessed such a case, but it seems like there must be correlation levels small enough that most reading is still scattered, but large enough to make a difference in the cost estimates between the two competing access methods that favor the one that is not actually faster. >From my attempted reading of the thread "posix_fadvise v22", it seems like modification of the planner was never discussed, rather than being discussed and rejected. So, is there a reason not to make the planner take account of effective_io_concurrency? But it might be better yet to make ordinary index scans benefit from effective_io_concurrency, but even if/when that gets done it would probably still be worthwhile to make the planner understand the benefit. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers