Обсуждение: Tables larger than 1GB

Поиск
Список
Период
Сортировка

Tables larger than 1GB

От
nolan@celery.tssi.com
Дата:
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?
--
Mike Nolan

Re: Tables larger than 1GB

От
"Shridhar Daithankar"
Дата:
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.