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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: How to improve db performance with $7K?
Дата
Msg-id 446.1113489854@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: How to improve db performance with $7K?  (Kevin Brown <kevin@sysexperts.com>)
Ответы Re: How to improve db performance with $7K?
Re: How to improve db performance with $7K?
Список 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 по дате отправления:

Предыдущее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: Foreign key slows down copy/insert
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: Foreign key slows down copy/insert