effective_io_concurrency

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