Re: Bitmap table scan cost per page formula

I've did some low level IO benchmarking, and I actually get 13 times slower to read every 3rd block than every block using CentOS6.9 with ext4 and the setting:

blockdev --setra 8192 /dev/sdb1

On some virtualized storage which I don't know the details of, but it  behaves as if it were RAID/JBOD with around 6 independent spindles..

If I pick the 1/3 of the blocks to read stochastically rather than by modulus, it is only 2 times slower than reading all of them, I assume because having occasional reads which are adjacent to each other does make read-ahead kick in, while evenly spaced never-adjacent reads does not.  This is probably a better model of how bitmap table scans actually work, as there is no general reason to think they would be evenly spaced and non-adjacent.  So this result is in reasonable agreement with how the current cost estimation works, the parabola peaks at about twice the cost as the sequence scan. 

I used a file of about 10GB, because I happened to have one laying around.

## read every block ($_%3>5 is never true)

sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

## read every 3rd block

sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

time perl -le 'open my $fh, "rand" or die; foreach (1..1300000) {$x=""; next if $_%3>0; sysseek $fh,$_*8*1024,0 or die $!; sysread $fh, $x,8*1024; print length $x} '|uniq -c

real    8m54.698s

Dropping the caches is a reasonable way to do this type of benchmark, because it simulates what would happen if your data set was much larger than RAM, without needing to actually use a data set much larger than RAM.