On Wed, 2005-03-09 at 13:07, Greg Stark wrote: > Scott Marlowe <smarlowe@xxxxxxxxxxxxxxxxx> writes: > > > With the advent of very large raid arrays with very fast caching > > controllers, this methodology is becoming less and less necessary. > > I think the evidence is to the contrary. Witness the rather dramatic surge in > inquiries about this on this list. A year ago there were only two or three of > us pining for this feature. Now it's a weekly refrain. > > Very large very fast raid arrays just mean that people want to gather that > much more data. They would still like to make the best use of their hardware > and not waste their resources on tremendously inefficient purging and loading > procedures when it would be possible to do these things instantaneously. That > only becomes more important as the investment they want to leverage becomes > larger. Actually, I think it is the more common scenario of migrating off of oracle or db2 and onto postgresql, and bringing along the experience gained there over the years that has caused this refrain to sprout up more and more often. With a database sitting on an enterpries class storage subsystem with 8 gigs of battery backed cache onboard, the needs for partitioning are less and less necessary. Not completely so, and there are times when they can come in handy (i.e. when you have to "roll your own" on a more limited budget). I'm note sure what your point about purging and loading is. A properly built home rolled partitioning setup reqiures none of that. it's just that whereas Oracle does it semi-automagically, the postgresql dba sets up the equivalent by hand. No purging or loading that I'm aware of is needed. Witness how often OTHER issues pop up (=NULL versus IS NULL, autonomous transactions, quotas) that are from oracle land nowadays. It isn't that the Oracle way is always the best way, it's just what folks are often used to. I really didn't see anything in your post that argued against my point that a large enterprise class raid array largely eliminates the needs for application level partitioning of data. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx
