Re: Tables larger than 1GB - Mailing list pgsql-general

From Shridhar Daithankar
Subject Re: Tables larger than 1GB
Date
Msg-id 3F083DC8.12246.B299A@localhost
Whole thread Raw
In response to Tables larger than 1GB  (nolan@celery.tssi.com)
List pgsql-general
On 4 Jul 2003 at 19:59, nolan@celery.tssi.com wrote:

> I know that when a table grows to the point where it is larger than 1GB,
> the backend opens up a 2nd data file.  (And a 3rd when it grows beyond
> 2GB, etc.)
>
> By testing it, I have learned that what it does (at least on a Linux box)
> is to create a file with a numbered extension appended to the name, ie,
> if the first file name is 1234567 the 2nd file is 1234567.1, then
> 1234567.2, etc.  (I wil continue to use these file names for illustration.)
>
> Currently, if I want to place a file on a separate physical drive for
> performance considerations, I can move the data file and leave a symbolic
> link in the appropriate subdirectory under ~/base.
>
> Having tried it, if I create an empty file named 1234567.1 in another
> directory and a symbolic link to it in the ~/base tree, it appears to
> roll over to that file properly.
>
> Is this practice an acceptable strategy, and would it work for index files
> as well?  Are there any conditions under which this would cause problems?

Yes. In case you recreate an index, that will be created in original place
rather than new place.

You can symlink an entire database to new place. That should not cause a
problem as it is hold in a directory. But as soon as you recreate a database
you aer back to square one.

Correct solution is tablespaces which is in design phase, to be optimistic.

Bye
 Shridhar

--
Steele's Law:    There exist tasks which cannot be done by more than ten men    or
fewer than one hundred.


pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: float formating with xx.00
Next
From: Mat
Date:
Subject: Sequence Roll Over