Re: How to improve db performance with $7K?

From: "Mohan, Ross" <RMohan(at)arbinet(dot)com>
To: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: How to improve db performance with $7K?
Date: 2005-04-19 14:34:51
Message-ID: CC74E7E10A8A054798B6611BD1FEF4D30625DA66@vamail01.thexchange.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Good question. If the SCSI system was moving the head from track 1 to 10, and a request then came in for track 5, could the system make the head stop at track 5 on its way to track 10? That is something that only the controller could do. However, I have no idea if SCSI does that.

|| SCSI, AFAIK, does NOT do this. What SCSI can do is allow "next" request insertion into head
of request queue (queue-jumping), and/or defer request ordering to done by drive per se (queue
re-ordering). I have looked, in vain, for evidence that SCSI somehow magically "stops in the
middle of request to pick up data" (my words, not yours)

The only part I am pretty sure about is that real-world experience shows SCSI is better for a mixed I/O environment. Not sure why, exactly, but the command queueing obviously helps, and I am not sure what else does.

|| TCQ is the secret sauce, no doubt. I think NCQ (the SATA version of per se drive request reordering)
should go a looong way (but not all the way) toward making SATA 'enterprise acceptable'. Multiple
initiators (e.g. more than one host being able to talk to a drive) is a biggie, too. AFAIK only SCSI
drives/controllers do that for now.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(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

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Simon Riggs 2005-04-19 14:46:33 Re: Postgresql works too slow
Previous Message Tom Lane 2005-04-19 14:06:40 Re: Question on REINDEX