Re: [GENERAL] Physical Database Configuration - Mailing list pgsql-hackers

From nolan@celery.tssi.com
Subject Re: [GENERAL] Physical Database Configuration
Date
Msg-id 20030625200247.20592.qmail@celery.tssi.com
Whole thread Raw
In response to Re: [GENERAL] Physical Database Configuration  ("Andrew Dunstan" <andrew@dunslane.net>)
List 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 by date:

Previous
From: greg@turnstep.com
Date:
Subject: Re: Updating psql for features of new FE/BE protocol
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Many Pl/PgSQL parameters -> AllocSetAlloc(128)?