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(at)candle(dot)pha(dot)pa(dot)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)