Re: How to REINDEX in high volume environments? - Mailing list pgsql-hackers
From | Shridhar Daithankar |
---|---|
Subject | Re: How to REINDEX in high volume environments? |
Date | |
Msg-id | 3D96FB86.9223.8D42317@localhost Whole thread Raw |
In response to | Re: How to REINDEX in high volume environments? (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On 28 Sep 2002 at 12:18, Tom Lane wrote: > Justin Clift <justin@postgresql.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.. ByeShridhar -- The sooner our happiness together begins, the longer it will last. -- Miramanee, "The Paradise Syndrome", stardate 4842.6
pgsql-hackers by date: