Re: Big 7.1 open items

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026