Skip site navigation (1) Skip section navigation (2)

AW: Big 7.1 open items

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Mikheev, Vadim'" <vmikheev(at)SECTORBASE(dot)COM>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: Big 7.1 open items
Date: 2000-06-28 09:11:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > > > 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
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
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 ...)



pgsql-hackers by date

Next:From: Hiroshi InoueDate: 2000-06-28 10:47:43
Subject: Re: AW: Big 7.1 open items
Previous:From: Zeugswetter Andreas SBDate: 2000-06-28 08:26:22
Subject: AW: AW: Proposal: More flexible backup/restore via pg_dump

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group