Greg,
> I think this seems pretty impractical for regular
> (non-bitmap) index probes though. You might be able to do it
> sometimes but not very effectively and you won't know when it
> would be useful.
Maybe so, though I think it's reasonable to get multiple actuators going
even if the seeks are truly random. It's a dynamic / tricky business to
determine how many pending seeks to post, but it should be roughly close
to the number of disks in the pool IMO.
> I think what this means is that there are actually *three*
> kinds of i/o: 1) Sequential which means you get the full
> bandwidth of your drives * the number of spindles; 2) Random
> which gets you 1 block per seek latency regardless of how
> many spindles you have; and 3) Random but with prefetch which
> gets you the random bandwidth above times the number of spindles.
Perhaps so, though I'm more optimistic that prefetch would help most
random seek situations.
For reasonable amounts of concurrent usage this point becomes moot - we
get the benefit of multiple backends doing seeking anyway, but I think
if we do dynamic prefetch right it would degenerate gracefully in those
circumstances.
> The extra spindles speed up sequential i/o too so the ratio
> between sequential and random with prefetch would still be
> about 4.0. But the ratio between sequential and random
> without prefetch would be even higher.
Right :-)
- Luke