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

From Richard_D_Levine@raytheon.com
Subject Re: How to improve db performance with $7K?
Date
Msg-id OF74B315AF.D4C3F1C2-ON05256FDC.00559FCC-05256FDC.0055D617@ftw.us.ray.com
Whole thread Raw
In response to Re: How to improve db performance with $7K?  ("Douglas J. Trainor" <trainor@transborder.net>)
Responses Re: How to improve db performance with $7K?
List pgsql-performance
Another simple question: Why is SCSI more expensive?  After the
eleventy-millionth controller is made, it seems like SCSI and SATA are
using a controller board and a spinning disk.  Is somebody still making
money by licensing SCSI technology?

Rick

pgsql-performance-owner@postgresql.org wrote on 04/06/2005 11:58:33 PM:

> You asked for it!  ;-)
>
> If you want cheap, get SATA.  If you want fast under
> *load* conditions, get SCSI.  Everything else at this
> time is marketing hype, either intentional or learned.
> Ignoring dollars, expect to see SCSI beat SATA by 40%.
>
>      * * * What I tell you three times is true * * *
>
> Also, compare the warranty you get with any SATA
> drive with any SCSI drive.  Yes, you still have some
> change leftover to buy more SATA drives when they
> fail, but... it fundamentally comes down to some
> actual implementation and not what is printed on
> the cardboard box.  Disk systems are bound by the
> rules of queueing theory.  You can hit the sales rep
> over the head with your queueing theory book.
>
> Ultra320 SCSI is king of the hill for high concurrency
> databases.  If you're only streaming or serving files,
> save some money and get a bunch of SATA drives.
> But if you're reading/writing all over the disk, the
> simple first-come-first-serve SATA heuristic will
> hose your performance under load conditions.
>
> Next year, they will *try* bring out some SATA cards
> that improve on first-come-first-serve, but they ain't
> here now.  There are a lot of rigged performance tests
> out there...  Maybe by the time they fix the queueing
> problems, serial Attached SCSI (a/k/a SAS) will be out.
> Looks like Ultra320 is the end of the line for parallel
> SCSI, as Ultra640 SCSI (a/k/a SPI-5) is dead in the
> water.
>
> Ultra320 SCSI.
> Ultra320 SCSI.
> Ultra320 SCSI.
>
> Serial Attached SCSI.
> Serial Attached SCSI.
> Serial Attached SCSI.
>
> For future trends, see:
> http://www.incits.org/archive/2003/in031163/in031163.htm
>
>     douglas
>
> p.s. For extra credit, try comparing SATA and SCSI drives
> when they're 90% full.
>
> On Apr 6, 2005, at 8:32 PM, Alex Turner wrote:
>
> > I guess I'm setting myself up here, and I'm really not being ignorant,
> > but can someone explain exactly how is SCSI is supposed to better than
> > SATA?
> >
> > Both systems use drives with platters.  Each drive can physically only
> > read one thing at a time.
> >
> > SATA gives each drive it's own channel, but you have to share in SCSI.
> >  A SATA controller typicaly can do 3Gb/sec (384MB/sec) per drive, but
> > SCSI can only do 320MB/sec across the entire array.
> >
> > What am I missing here?
> >
> > Alex Turner
> > netEconomist
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
your
>       joining column's datatypes do not match


pgsql-performance by date:

Previous
From: John Arbash Meinel
Date:
Subject: Re: Any way to speed this up?
Next
From: Tom Lane
Date:
Subject: Re: help on explain analyse in psql 7.1.3 (linux)