Async I/O

Bruce Momjian wrote:

> My conclusion from this is that we really are not going to gain a lot of
> speed by exploring some async solution, because if the data we need is
> not in the cache, we really are going to spend most of our time waiting
> for disk I/O.
>
> Comments?

Well, I've just found an intersting article on AFP (Asynchronous
Prefetch) at Sybase site.

http://www.sybase.com/Partners/sun/apftech.html

What is worth to note, and you seem to forget. If your app is spending
it's time on waiting for single IO operation, you want save anything.
However, if you manage to have multiple I/O requests served
asynchronically you may get better performance on RAID systems, also
your I/O hardware may work better since the controllers may batch
requests, requeue them and optimise them (Of course not in case of IDE
disks).

Also, somebody asked about clustered indexes. I was looking for
informations on this technique at Sybase (which is a great source of
information on various DB hints). If you read above document between
lines, the conclusion comes that clustered index is something that
allows the data from table to be mixed with index. I suppose that index
pages are clustered with data pages so if you find aproporiate record in
index, the data that this index entry points to is on the same page or
close.

At Sybase I have also found some interesting materials on Bitmap Indexes
(this idea is relatively simple) which looks very interesting in case of
some types of queries.

Mike

--
WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND