> -----Original Message----- > From: Alex Turner [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 20, 2005 12:04 PM > To: Dave Held > Cc: pgsql-performance@postgresql.org > Subject: Re: [PERFORM] How to improve db performance with $7K? > > [...] > Lets say we invented a new protocol that including the drive telling > the controller how it was layed out at initialization time so that the > controller could make better decisions about re-ordering seeks. It > would be more cost effective to have that set of electronics just once > in the controller, than 8 times on each drive in an array, which would > yield better performance to cost ratio.
Assuming that a single controller would be able to service 8 drives without delays. The fact that you want the controller to have fairly intimate knowledge of the drives implies that this is a semi-soft solution requiring some fairly fat hardware compared to firmware that is hard-wired for one drive. Note that your controller has to be 8x as fast as the on-board drive firmware. There's definitely a balance there, and it's not entirely clear to me where the break-even point is. > Therefore I would suggest it is something that should be investigated. > After all, why implemented TCQ on each drive, if it can be handled more > effeciently at the other end by the controller for less money?! Because it might not cost less. ;) However, I can see where you might want the controller to drive the actual hardware when you have a RAID setup that requires synchronized seeks, etc. But in that case, it's doing one computation for multiple drives, so there really is a win. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
