> 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
