Re: How to improve db performance with $7K? - Mailing list pgsql-performance

From Dave Held
Subject Re: How to improve db performance with $7K?
Date
Msg-id 49E94D0CFCD4DB43AFBA928DDD20C8F9026184B1@asg002.asg.local
Whole thread Raw
In response to How to improve db performance with $7K?  (Steve Poe <spoe@sfnet.cc>)
List pgsql-performance
> -----Original Message-----
> From: Mohan, Ross [mailto:RMohan@arbinet.com]
> Sent: Thursday, April 14, 2005 1:30 PM
> To: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] How to improve db performance with $7K?
>
> Greg Stark wrote:
> >
> > Kevin Brown <kevin@sysexperts.com> 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:

http://www.linuxjournal.com/article/6931

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

pgsql-performance by date:

Previous
From: Steve Poe
Date:
Subject: Re: How to improve db performance with $7K?
Next
From: Alvaro Herrera
Date:
Subject: Re: [Fwd: Re: Functionscan estimates]