Re: [GENERAL] Physical Database Configuration

nolan(at)celery(dot)tssi(dot)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