Re: Table Partitioning in Postgres:
От | Greg Copeland |
---|---|
Тема | Re: Table Partitioning in Postgres: |
Дата | |
Msg-id | 1045674057.3295.54.camel@mouse.copelandconsulting.net обсуждение исходный текст |
Ответ на | Re: Table Partitioning in Postgres: (Jonathan Bartlett <johnnyb@eskimo.com>) |
Ответы |
Re: Table Partitioning in Postgres:
Re: Table Partitioning in Postgres: |
Список | pgsql-general |
On Wed, 2003-02-19 at 10:31, Jonathan Bartlett wrote: > > While your statement is correct I did want to clarify that IDE and SCSI > > were lumped together and they should not be. SCSI and IDE performance > > expectations differ because their bus technologies are dramatically > > different. IDE has some serious performance issues with multiple disks > > per channel. A single disk can effectively tie up an IDE channel for > > Actually, IDE has performance issues even with only 1 disk per channel. > The SCSI command set allows disconnected operations, so that the kernel > can send commands (get block xxx, get block yyy, get block zzz) and keep > sending commands while the drive processes the answers. With IDE, it is a > synchronous transmission - get blox xxx, wait until disk processes, > receive block xxx, get block yyy, wait until disk processes, receive block > yyy. SCSI disks can also reorder the requests and service them based on > how quickly it can get to each one. > > Even on one-channel-per-disk, SCSI wins out. > > Jon > Agreed. I think we are saying the same thing. You just happen to go into more detail. :P My point being, if you use IDE, you should be attempting to use a disk per channel. BTW, on a different note, IBM created some IDE drives which allow for command tagging which allows for multiple outstanding IDE commands, however, I have no idea what the availability of said drives and drivers are. I'm actually fairly ignorant on the exact device details. You wouldn't happen to have the skinny of those things would ya? They still being made? Your comments really serve to enforce that IDE stinks and stresses that IDE should not be used where serious database performance is needed. Needless to say, I think we all already understood that. ;) Regards, -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
В списке pgsql-general по дате отправления: