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