Re: [GENERAL] Physical Database Configuration

nolan@celery.tssi.com writes:
> I disagree.  Just as you can have multiple schemas within one database
> you can have multiple tablespaces within one database.  

> And the tablespace is irrelevant as far as specifying an object is concerned.
> A fully qualified object would be: 
>     database.schema.object,
> not tablespace.database.schema.object or database.tablespace.schema.object.

Right, the tablespace structure is really orthogonal to the
database/schema structure.

I would envision tablespaces as being named by database-cluster-wide
names, just as users and groups are.  Any given table could be placed
in any tablespace (although perhaps we want to invent some permission
mechanism here).

Physically a tablespace is a directory with sub-directories for
databases under it --- so $PGDATA/base plays the role of the default
tablespace for a cluster.  (The reason you need per-database
sub-directories is mostly to support DROP DATABASE, which has to be
able to nuke a database without knowing exactly what's in it.)  But
this structure doesn't have anything to do with the logical structure
of the database cluster.

There are a bunch of interesting locking issues to be solved, but the
storage layout ideas are pretty clear in my mind.
        regards, tom lane