Re: [HACKERS] [hackers]development suggestion needed

On Thu, 13 Jan 2000, Tom Lane wrote:

> Don Baccus <dhogaza@pacifier.com> writes:
> > This would need to be done to implement some sort of tablespace-style
> > facility, too, right?  I'm off Xun's thread in asking but I've been
> > wondering.  DBs like Oracle allow you to place tables and indices
> > whereever you like in the filesystem.  This is normally done to
> > distribute things across different spindles, and in large, busy
> > databases makes a significant difference.  I've done some experimenting
> > moving index files to a different spindle (using "ln" to fool 
> > postgres, of course) and insertions go measurably faster.  Spindles
> > are so cheap nowadays :)
> 
> As you say, you can fake it manually with symbolic links, but that's
> a kluge.
> 
> The "database location" stuff that Peter and Thomas have been arguing
> about is intended to allow a single postmaster to control databases that
> are in multiple physical locations --- but there seems to be some debate
> as to whether it works ;-).  (I never tried it.)  In any case, we don't
> currently have any official provision for controlling location at finer
> than database level.  It'd be nice to be able to push individual tables
> around, I suppose.
> 
> This wouldn't require a new storage manager, since presumably you'd
> still be using the Unix-filesystem storage manager.  The trick would be
> to allow a path rather than just a base file name to be specified
> per-relation.  I'm not sure if it'd be hard or not.  Probably, all the
> system tables would have to stay in the database's default directory,
> but maybe user tables could be given path names without too much
> trouble...

Okay, I've been thinking about this recently with the whole Udmsearch of
PostgreSQL.  We just put a 9gig drive online to handle this, as well as
other database related projects, since I wanted alot of room to grow
(PostgreSQL itself indexed out to something like 1gig, and the lists are
growing) ...

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?

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...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org