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
