> > Do we need *both* database & tablespace to find table file ?!
> > Imho, database shouldn't be used...
> 
> That'd work fine for me, but I think Bruce was arguing for paths that
> included the database name.  We'd end up with paths that go something
> like
> 	..../data/tablespaces/TABLESPACEOID/RELATIONOID
> (plus some kind of decoration for segment and version), so you'd have
> a hard time telling which files in a tablespace belong to which
> database.  Doesn't bother me a whole lot, personally --- if one wants

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.

Vadim

Mon, 26 Jun 2000 15:15:39 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Big 7.1 open items 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> 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 ;-)

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").

			regards, tom lane

Mon, 26 Jun 2000 18:48:22 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Big 7.1 open items 
Tom Lane wrote:

>
> 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.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



Tue, 27 Jun 2000 13:07:28 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: Big 7.1 open items
> Tom Lane wrote:
> 
> >
> > 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 will be a
little faster, and if we can make administration easier, why not?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 27 Jun 2000 00:16:49 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Big 7.1 open items
Bruce Momjian wrote:

> > Tom Lane wrote:
> >
> > >
> > > 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 will be a
> little faster, and if we can make administration easier, why not?
>

I  only objected to emphasize the advantage in getting useful per-database
numbers from "du".  It's only misleading in dbms design.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp


Tue, 27 Jun 2000 17:53:10 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: Big 7.1 open items