Re: Big 7.1 open items

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Yes, that is true.  My idea is that they may want to create loc1 and
> > loc2 which initially point to the same location, but later may be moved.
> > For example, one tablespace for tables, another for indexes.  They may
> > initially point to the same directory, but later be split.
> 
> Well, that opens up a completely different issue, which is what about
> moving tables from one tablespace to another?

Are you suggesting that doing dbname/locname is somehow harder to do
that?  If you are, I don't understand why.

The general issue of moving tables between tablespaces can be done from
in the database.  I don't think it is reasonable to shut down the db to
do that.  However, I can see moving tablespaces to different symlinked
locations may require a shutdown.

> 
> I think the way you appear to be implying above (shut down the server
> so that you can rearrange subdirectories by hand) is the wrong way to
> go about it.  For one thing, lots of people don't want to shut down
> their servers completely for that long, but it's difficult to avoid
> doing so if you want to move files by filesystem commands.  For another
> thing, the above approach requires guessing in advance --- maybe long
> in advance --- how you are going to want to repartition your database
> when it gets too big for your existing storage.
> 
> The right way to address this problem is to invent a "move table to
> new tablespace" command.  This'd be pretty trivial to implement based
> on a file-versioning approach: the new version of the pg_class tuple
> has a new tablespace identifier in it.

Agreed.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026