"Luke Lonergan" <llonergan@xxxxxxxxxxxxx> writes: > Right now the pattern for index scan goes like this: > > - Find qualifying TID in index > - Seek to TID location in relfile > - Acquire tuple from relfile, return >... > If we implement AIO and allow for multiple pending I/Os used to prefetch > groups of qualifying tuples, basically a form of random readahead Ah, I see what you mean now. It makes a lot more sense if you think of it for bitmap index scans. So, for example, the bitmap index scan could stream tids to the executor and the executor would strip out the block numbers and pass them to the i/o layer saying "i need this block now but following that I'll need these blocks so get them moving now". 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. 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. 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. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
