Re: [GENERAL] Physical Database Configuration

Поиск
Список
Период
Сортировка
От nolan@celery.tssi.com
Тема Re: [GENERAL] Physical Database Configuration
Дата
Msg-id 20030625200247.20592.qmail@celery.tssi.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Physical Database Configuration  ("Andrew Dunstan" <andrew@dunslane.net>)
Список pgsql-hackers
> DB2 looks good. I have horrid, horrid memories of wrestling with the Oracle
> "extent" madness.

I think Oracle's extents came from their fixed size data file legacy, in 9i 
the extent limits appear to be completely overridable and sometimes even
ignored, such as the next extent size.  I agree that the 128 extent limit 
was a pain, and the default for each new extent to be larger than the 
previous one created many problems.

Oracle also took physical abstraction one level beyond 'tablespaces'.
I think if each tablespace pointed to a specific directory, that'd be 
sufficient for me.  And since I envision the tablespace as an attribute 
of the table that should take care of the 1GB file rollover issue, as 
the rollover would occur in the same directory as the first file.

Without having delved into the code yet, setting up entries for user 
default tablespaces and system information is probably at least as much 
work as getting a tablespace to point to a specific directory for the 
purposes of opening or creating files for an object.

My personal preference would be to have four tablespaces predefined as part 
of a new database, though initially they could all point to the same place:

SYSTEM
USER
TEMP
INDEXES

What about the concepts of a 'read-only' tablespace, or taking tablespaces
offline?  
--
Mike Nolan


В списке pgsql-hackers по дате отправления:

Предыдущее
От: greg@turnstep.com
Дата:
Сообщение: Re: Updating psql for features of new FE/BE protocol
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Many Pl/PgSQL parameters -> AllocSetAlloc(128)?