> > > > 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").
> > >
> > > Our database design seems to be in the opposite direction
> > > if it is restricted for the convenience of command calls.
> >
> > Well, I don't see any reason not to use tablespace/database
> > rather than just tablespace. Seems having fewer files in
> each directory
>
> Once again - ability to use different tablespaces (disks) for
> tables/indices
> in the same schema. Schemas must not dictate where to store objects <-
> bad design.
Can we agree, that the schema is below the database hierarchy, and thus
is something different than a database ?
A table under another schema will simply get another oid, and thus no
collision.
But I agree that schema should not dictate storage location,
but the schema might imply a default storage location like in Oracle
(default tablespaces for a user).
> > will be a little faster, and if we can make administration easier,
> > why not?
>
> Because you'll not be able use du/ls once we'll implement new
> smgr anyway.
Leaving the file per table design imho does imply an order of magnitude
increase in the impact of errors in the smgr. Now an error is likely to
destroy
one table only, then it can destroy a whole tablespace.
But I am still a fan of the single file/raw device per tablespace design,
since it can remove a lot of the OS overhead.
> And, btw, - for what are we going implement tablespaces? Just to have
> fewer files in each dir ?!
No, I guess the idea is to have a tool to manipulate physical distribution
of objects (which disk, which filesystem ...)
Andreas
