RE: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development suggestion needed ) - Mailing list pgsql-hackers

From Ansley, Michael
Subject RE: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development suggestion needed )
Date
Msg-id 1BF7C7482189D211B03F00805F8527F748C440@S-NATH-EXCH2
Whole thread Raw
List pgsql-hackers
But it's not quite this simple.  In our production system, we have reference
data in one tablespace, reference indices in another, working data in a
third space, and work indices in a fourth.  This is because the amount of
working data throughput is extremely high, while the reference data,
although changing reasonably frequently, changes significantly less than the
working data.  This is then normally spread across five spindles, with
Oracle being in the fifth.  On a 32-processor HP.

I think a good solution is to be able to specify where on the disk the table
is created (absolute paths only), and then postgres symlinks that file in
the main data directory, so from that point on it referenced without the
path name.  That's probably a significant start.

Alternatively, we could create "directoryspaces", which treats a directory
as a tablespace.  Then you do this:

CREATE TABLE foo (id_foo int, name varchar(30)) TABLESPACE
"/data/pgdata/sys1ref";

to create the new file /data/pgdata/sys1ref/foo, and a symlink is created in
the main db directory, so that you can just SELECT * FROM foo;

This is not difficult at all, or am I missing something?  Only real issue
(possibly) is security regarding the tablespace.  It might be an idea to
allow only the superuser to add allowed directories (i.e.: "create"
tablespaces), and assign user access to those tablespaces.


MikeA




>> -----Original Message-----
>> From: The Hermit Hacker [mailto:scrappy@hub.org]
>> Sent: Friday, January 14, 2000 6:32 AM
>> To: Don Baccus
>> Cc: Tom Lane; Xun Cheng; pgsql-hackers@postgreSQL.org
>> Subject: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development
>> suggestion needed )
>> 
>> 
>> On Thu, 13 Jan 2000, Don Baccus wrote:
>> 
>> > My site's still in the experimental stage, being used by a couple
>> > dozen folks to record bird distribution data in the Pacific NW, so
>> > I don't personally have real-world data to get a feeling for how
>> > important this might become.  Still, Oracle DBA docs talk a lot
>> > about it so in some real-world scenarios being able to distribute
>> > tables and indices on different spindles must pay off.
>> 
>> What would it take to break the data/base/<database> 
>> directory down?  To
>> something like, maybe:
>> 
>> data/base/<database>/pg_*
>>                     /tables/*
>>                     /indices/*
>> 
>> Then, one could easily mount a drive as /tables and another one as
>> /indices ...
>> 
>> We know the difference between a table and an index, so I 
>> wouldn't think
>> it would be *too* hard add /tables/ internally to the existing
>> path...would it?
>> 
>> You'd basically have somethign like:
>> 
>> sprintf("%s/data/base/%s/tables/%s", data_dir, database, tablename);
>> 
>> Instead of:
>> 
>> sprintf("%s/data/base/%s/%s", data_dir, database, tablename);
>> 
>> I know, I'm being simplistic here, but...
>> 
>> Or, a different way:
>> 
>> if(table) sprintf("%s/data/base/table/%s/%s", 
>> data_dir,database,tablename);
>> else if(index) sprintf("%s/data/base/index/%s/%s", 
>> data_dir,database,tablename);
>> else sprintf("%s/data/base/sys/%s/%s", data_dir,database,sysfile);
>> 
>> This would give you the ability to put all table from all 
>> databass onto
>> one file system, and all indexes onto another, and all 
>> system files onto a
>> third...
>> 
>> I don't know, I'm oversimplying and spewing thoughts out
>> again...but...*shrug*
>> 
>> Marc G. Fournier                   ICQ#7615664               
>> IRC Nick: Scrappy
>> Systems Administrator @ hub.org 
>> primary: scrappy@hub.org           secondary: 
>> scrappy@{freebsd|postgresql}.org 
>> 
>> 
>> ************
>> 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development suggestion needed )
Next
From: Michael Meskes
Date:
Subject: Re: [HACKERS] FETCH without FROM/IN