> > We could create /data/databases/DATABASEOID/ and create
> > soft-links to table-files. This way different tables of
> > the same database could be in different tablespaces.
> > /data/database path would be used in production
> > and /data/tablespace path would be used in recovery.
>
> Why would you want to do it that way? Having a different access path
> for recovery than for normal operation strikes me as just asking for
> trouble ;-)
I just think that *databases* (schemas) must be used for *logical* groupping
of tables, not for *physical* one. "Where to store table" is tablespace'
related kind of things!
> The symlinks wouldn't do any good for what Bruce had in mind anyway
> (IIRC, he wanted to get useful per-database numbers from "du").
Imho, ability to put different tables/indices (of the same database)
to different tablespaces (disks) is much more useful then ability to
use du/ls for administration purposes -:)
Also, I think that we *must* go away from OS' driven disk space
allocation anyway. Currently, the way we extend table files breaks WAL
rule (nothing must go to disk untill logged). + we have to move tuples
from end of file to top to shrink relation - not perfect way to reuse
empty space. +... +... +...
Vadim
