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

Re: Big 7.1 open items

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Subject: Re: Big 7.1 open items
Date: 2000-06-27 21:23:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Well, that would allow us to mix database files in the same directory,
> > if we wanted to do that.  My opinion it is better to keep databases in
> > separate directories in each tablespace for clarity and performance
> > reasons.
> One reason not to do that is that we'd still have to special-case
> the system-wide relations.  If it's just tablespace and OID in the
> path, then the system-wide rels look just the same as any other rel
> as far as the low-level stuff is concerned.  That would be nice.

Yes, good point about pg_shadow.  They don't have databases.  How do we
get multiple pg_class tables in the same directory?  Is the
pg_class.relversion file a number like 1,2,3,4, or does it come out of
some global counter like oid.  If so, we could put them in the same

Should we be concerned about performance when 10-20 database are sitting
in the same directory?  I am thinking about open() and other calls that
scan the directory.  Certainly shorter file names will help.

> My feeling about the "clarity and performance" issue is that if a
> dbadmin wants to keep track of database contents separately, he can
> put different databases' tables into different tablespaces to start
> with.  If he puts several tables into one tablespace, he's saying
> he doesn't care about distinguishing their space usage.  There's
> no reason for us to force an additional level of directory lookup
> to be done whether the admin wants it or not.


  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2000-06-27 21:30:17
Subject: Re: Big 7.1 open items
Previous:From: Tom LaneDate: 2000-06-27 21:19:31
Subject: Re: Big 7.1 open items

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