Re: Async I/O

> 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).

Yes, perhaps using readv would be a win, and perhaps easy to do.

>
> 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.

Sounds a lot like ISAM to me.  And ISAM is a big win for static tables
if you need throughput.  Remember the word fragment issue, which
CLUSTER fixed.  I had an Ingres word fragment app that was terrible on
btree, and Marteen experienced.  CLUSTER does simulate that for static
tables, so it may not be such a big win.  I suppose if you needed such
performance, and the table changed a lot, it may be good.

>
> 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
>


--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)