Re: How to REINDEX in high volume environments?

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

> Justin Clift <justin(at)postgresql(dot)org> 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