> -----Original Message-----
> From: Mohan, Ross [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 1:30 PM
> To: email@example.com
> Subject: Re: [PERFORM] How to improve db performance with $7K?
> Greg Stark wrote:
> > Kevin Brown <[EMAIL PROTECTED]> writes:
> > > Greg Stark wrote:
> > >
> > > > I think you're being misled by analyzing the write case.
> > > >
> > > > Consider the read case. When a user process requests a block
> > > > and that read makes its way down to the driver level, the
> > > > driver can't just put it aside and wait until it's convenient.
> > > > It has to go ahead and issue the read right away.
> > >
> > > Well, strictly speaking it doesn't *have* to. It could delay
> > > for a couple of milliseconds to see if other requests come in,
> > > and then issue the read if none do. If there are already other
> > > requests being fulfilled, then it'll schedule the request in
> > > question just like the rest.
> > But then the cure is worse than the disease. You're basically
> > describing exactly what does happen anyways, only you're
> > delaying more requests than necessary. That intervening time
> > isn't really idle, it's filled with all the requests that
> > were delayed during the previous large seek...
> > [...]
> 1) some SATA drives (just type II, I think?) have a "Phase Zero"
> implementation of Tagged Command Queueing (the special sauce
> for SCSI).
> Largely b/c of 2 and 3, multi-initiator SCSI RAID'ed drives
> are likely to whomp SATA II drives for a while yet (read: a
> year or two) in multiuser PostGres applications.
I would say it depends on the OS. What Kevin is describing sounds
just like the Anticipatory I/O Scheduler in Linux 2.6:
For certain application contexts, it looks like a big win. Not
entirely sure if Postgres is one of them, though. If SCSI beats
SATA, it sounds like it will be mostly due to better seek times.
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]