Re: [HACKERS] [hackers]development suggestion needed - Mailing list pgsql-hackers
From | Don Baccus |
---|---|
Subject | Re: [HACKERS] [hackers]development suggestion needed |
Date | |
Msg-id | 3.0.1.32.20000113212111.010834c0@mail.pacifier.com Whole thread Raw |
In response to | Re: [HACKERS] [hackers]development suggestion needed (The Hermit Hacker <scrappy@hub.org>) |
Responses |
Re: [HACKERS] [hackers]development suggestion needed
|
List | pgsql-hackers |
At 12:21 AM 1/14/00 -0400, The Hermit Hacker wrote: >All the major OSs out there have "disk management tools" that allow you to >build "large file systems" out of smaller ones... Solaris has DiskSuite, >FreeBSD has vinum, Linux has ??... why are we looking/investigating adding >a level of complexity to PostgreSQL to handle something that, as far as I >know, each of the OSs out there already has a way of dealing with? If the resident OS can handle the issue, sure, it is worth investigating. Linux today does not (at least, the one I'm running). One godliness-over-utility issue is the fact that doing such things in the operating system ("ln" also works...) kinda violates the RDBMS ideal of having everything about a database, including metadata, stored in the database. In the case of "CREATE TABLESPACE" having Postgres handle placement places the burden of operating system specifics where it belongs - on the implementation. This is why we say things like "integer" or "numeric", come to think of it... The word "portability" comes to mind, though of course things like spindle numbers and the like are extremely variable. >Some aren't necessarily mature yet...Solaris's is the only one that I'm >aware of that has a *beautiful* growfs program that allows you to add a >new drive to an existing "pack" and grow the file system into that new >drive while the system is live...but the utilities are there... > >I think the major problem that I'm worried about isn't spreading tables >across drives, but its when that *one* table grows to the point that its >about to overflow my drive...I'd rather add a 9gig drive on, make it an >18gig file system, and let it continue to grow... These aren't mutally exclusive problems, which is one reason why Oracle allows you to control things so minutely. I think they let you spill a table onto multiple drives, though I'd have to look at one of my manuals hidden in my piles of more interesting things (I'm no Oracle expert, I just read manuals :) There is definitely a sort of tension between the operating systems, which continue to grow in capability such as you're pointing out, and commercial systems like Oracle that have to work TODAY regardless of where operating systems sit on the capability yardstick. Thus Oracle includes built-in mirroring, while today under Linux you might as well do software RAID 1, or you can buy a hardware device that does RAID 1 behind your back and looking like a single drive no matter how many platter you stuff it with, etc etc. So...you'll never hear me argue that Postgres should include a mirroring storage manager. There is no longer the need for an application to do it on its own in the supported OS space (hmmm...I'm assuming FreeBSD is there, too, right?) So maybe the notion of application placement of files on particular spindles is becoming obsolete, too. It isn't today on Linux... - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
pgsql-hackers by date: