From: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
---|---|
To: | PgSQL General ML <pgsql-general(at)postgresql(dot)org> |
Subject: | Table spaces (was Re: State of Beta 2) |
Date: | 2003-09-15 07:57:24 |
Message-ID: | 1063612643.11739.1181.camel@haggis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, 2003-09-14 at 23:08, Tom Lane wrote:
> Network Administrator <netadmin(at)vcsn(dot)com> writes:
> > ... However it seems to me that right now that this might not be
> > possible while the backend is changing between major releases.
> > Perhaps once that doesn't fluxate as much it might be feasible to
> > create these layer so that it is not too fat.
>
> Yeah, that's been in the back of my mind also. Once we have tablespaces
> and a couple of the other basic features we're still missing, it might
> be a more reasonable proposition to freeze the on-disk representation.
I think that every effort should be made so that the on-disk struct-
ure (ODS) doesn't have to change when tablespaces is implemented.
I.e., oid-based files live side-by-side with tablespaces.
At a minimum, it should be "ok, you don't *have* to do a dump/restore
to migrate to v7.7, but if you want the tablespaces that are brand
new in v7.7, you must dump data, and recreate the schema with table-
spaces before restoring".
--
-----------------------------------------------------------------
Ron Johnson, Jr. ron(dot)l(dot)johnson(at)cox(dot)net
Jefferson, LA USA
"(Women are) like compilers. They take simple statements and
make them into big productions."
Pitr Dubovitch
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Johnson | 2003-09-15 08:05:10 | Re: [PERFORM] best arrangement of 3 disks for (insert) performance |
Previous Message | Dennis Gearon | 2003-09-15 06:52:40 | Re: case-insensitive database |