On Wed, 2005-03-09 at 13:07, Greg Stark wrote:
> Scott Marlowe <smarlowe@g2switchworks.com> 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.
