Skip site navigation (1) Skip section navigation (2)

Re: Async I/O

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: mimo(at)interdata(dot)com(dot)pl (Michal Mosiewicz)
Cc: hackers(at)postgresql(dot)org
Subject: Re: Async I/O
Date: 1998-05-16 02:29:50
Message-ID: 199805160229.WAA27203@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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)

In response to

  • Async I/O at 1998-05-16 00:08:27 from Michal Mosiewicz

pgsql-hackers by date

Next:From: Thomas G. LockhartDate: 1998-05-16 02:40:14
Subject: Re: [HACKERS] Sequential scan speed, mmap, disk i/o
Previous:From: Thomas G. LockhartDate: 1998-05-16 02:00:07
Subject: Re: CREATE DATABASE

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group