On Mon, Nov 14, 2011 at 4:55 AM, Thom Brown <t...@linux.com> wrote: > So can I humbly request we completely re-architect the whole of > PostgreSQL to fit this feature? Thanks.
Heh. I have to admit I've thought about this from time to time, and it would be pretty cool. I was initially thinking that it wouldn't be that difficult to do this on a per-database level, because if you slurp up a whole database then by definition you're also including the system catalogs, which means that you have the pg_class, pg_attribute, and pg_type entries that are necessary to interpret the table contents. If you do anything more fine-grained (per-tablespace, per-table, or whatever) then things get much more complex, but at the database level you only need to worry about interactions with other globals: tablespace and role definitions. And we could probably write code to grovel through the system catalogs for a newly "mounted" database and do search and replace on the appropriate columns, to map from the old OIDs to the new ones. It wouldn't be simple, but I think it could be done. But Tom's point about XIDs and LSNs seems like it kind of puts a bullet through the heart of the whole idea. Now, before you can move the database (or table, or whatever) between clusters, you've got to rewrite all the data files to freeze XIDs and, I don't know, zero out LSNs, or something. And if you're going to rewrite all the data, then you've pretty much lost all the benefit of doing this in the first place. In fact, it might end up being *slower* than a dump and restore; even an uncompressed dump will be smaller than the on-disk footprint of the original database, and many dumps compress quite well. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
