Re: Tables larger than 1GB

Поиск
Список
Период
Сортировка
От Shridhar Daithankar
Тема Re: Tables larger than 1GB
Дата
Msg-id 3F083DC8.12246.B299A@localhost
обсуждение исходный текст
Ответ на Tables larger than 1GB  (nolan@celery.tssi.com)
Список 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 по дате отправления:

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: float formating with xx.00
Следующее
От: Mat
Дата:
Сообщение: Sequence Roll Over