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

From Tom Lane
Subject Re: How to improve db performance with $7K?
Date
Msg-id 446.1113489854@sss.pgh.pa.us
Whole thread Raw
In response to Re: How to improve db performance with $7K?  (Kevin Brown <kevin@sysexperts.com>)
Responses Re: How to improve db performance with $7K?
Re: How to improve db performance with $7K?
List pgsql-performance
Kevin Brown <kevin@sysexperts.com> writes:
> I really don't see how this is any different between a system that has
> tagged queueing to the disks and one that doesn't.  The only
> difference is where the queueing happens.  In the case of SCSI, the
> queueing happens on the disks (or at least on the controller).  In the
> case of SATA, the queueing happens in the kernel.

That's basically what it comes down to: SCSI lets the disk drive itself
do the low-level I/O scheduling whereas the ATA spec prevents the drive
from doing so (unless it cheats, ie, caches writes).  Also, in SCSI it's
possible for the drive to rearrange reads as well as writes --- which
AFAICS is just not possible in ATA.  (Maybe in the newest spec...)

The reason this is so much more of a win than it was when ATA was
designed is that in modern drives the kernel has very little clue about
the physical geometry of the disk.  Variable-size tracks, bad-block
sparing, and stuff like that make for a very hard-to-predict mapping
from linear sector addresses to actual disk locations.  Combine that
with the fact that the drive controller can be much smarter than it was
twenty years ago, and you can see that the case for doing I/O scheduling
in the kernel and not in the drive is pretty weak.

            regards, tom lane

pgsql-performance by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Foreign key slows down copy/insert
Next
From: Stephan Szabo
Date:
Subject: Re: Foreign key slows down copy/insert