On 28 Sep 2002 at 12:18, Tom Lane wrote:

> Justin Clift <[EMAIL PROTECTED]> writes:
> > Shridhar Daithankar wrote:
> >> Looks like we should have a subdirectory in database directory which stores
> >> index.
> 
> > That was my first thought also, but an alternative/additional approach
> > would be this (not sure if it's workable):
> 
> See the tablespaces TODO item.  I'm not excited about building
> half-baked versions of tablespaces before we get around to doing the
> real thing ...

I wen thr. the messages posted regarding tablespaces. It looks like

Tablesspaces should provide

1. Managability 
2. Performance tuning
3. Better Administration..

Creating a directory for each object or object type would allow to do same 
thing.

Why directory?

1. You can mount it someplace else.
2. You can symlink it without worrying about postgresql creating new files 
instead of symlink while drop/recreate.

Whether to choose directory or tablespaces? I say directory. Why?

1. PostgreSQL philosphy has always been using facilities provided by OS and not 
to duplicate that work. Tablespaces directly violates that. Directory mounting 
does not.

2. Tablespaces combines objects on them, adding a layer of abstraction. and 
then come ideas like vacuuming a tablespace. Frankly given what vacuum does, I 
can't imagine what vacuuming tablespace would exactly do.

3. Tablespace would be a single file or structure of directories? How do we 
configure it? What tuning option do we provide?

Basically table spaces I feel is a layer of abstraction that can be avoided if 
we layout the DB in a directory tree with sufficient levels. That would be easy 
to deal with as configuration and maitainance delegated to OS and it would be 
flexible enough to.

Anyway if we have a directory per object/object type, how much different it's 
going to be from a table space? 

Frankly I am wary of table spaces because I have seen them in oracle and not 
eaxctly convinced that's the best way of doing things. 

If we introdude word tablespace, users will be expecting all those idiocies 
like taking a table space offline/online, adding data files aka pre-claiming 
space etc. All these are responsibilities of OS. Let OS handle it. PostgreSQL 
should just create a file structure which would grow as and when required.

The issue looks similimar to having raw disk I/O. Oracle might have good reason 
to do it but are we sure postgresql needs this? Just another policy decision 
waiting..

Here are some links I found in archive. Would like to know more about this 
issue..

http://candle.pha.pa.us/mhonarc/todo.detail/tablespaces/msg00006.html
http://candle.pha.pa.us/mhonarc/todo.detail/tablespaces/msg00007.html

Just a thought..

Bye
 Shridhar

--
The sooner our happiness together begins, the longer it will last.              -- 
Miramanee, "The Paradise Syndrome", stardate 4842.6


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to