| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
| Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, "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-28 17:39:32 |
| Message-ID: | 16404.962213972@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> Why do we have to have system tables per *database* ?
> Is there anything wrong with global system tables ?
> And how about adding dbid to pg_class,pg_proc etc ?
We could, but I think I'd vote against it on two grounds:
1. Reliability. If something corrupts pg_class, do you want to
lose your whole installation, or just one database?
2. Increased locking overhead/loss of concurrency. Currently, there
is very little lock contention between backends running in different
databases. A shared pg_class will be a single point of locking (as
well as a single point of failure) for the whole installation.
It would solve the DROP DATABASE problem kind of nicely, but really
it'd just be downgrading DROP DATABASE to a DROP SCHEMA operation...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Karel Zak | 2000-06-28 18:26:59 | Re: Misc. consequences of backend memory management changes |
| Previous Message | Hiroshi Inoue | 2000-06-28 17:28:45 | RE: Big 7.1 open items |