From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ben Clewett <B(dot)Clewett(at)roadrunner(dot)uk(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: For the ametures. (related to "Are we losing momentum?") |
Date: | 2003-04-17 14:35:31 |
Message-ID: | 10506.1050590131@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ben Clewett <B(dot)Clewett(at)roadrunner(dot)uk(dot)com> writes:
> - The tables (not innodb) are in different files of the same name.
> Allowing the OS adminitrator great ability. EG, putting tables on
> separate partitions and therefore greatly speeding performance.
FWIW, we used to do it that way too, many releases ago. We gave it up
because it was impossible to support rollback of table deletion/rename
with that storage rule underneath. Consider
BEGIN;
DROP TABLE a;
CREATE TABLE a (with-some-other-schema);
-- oops, think better of it
ROLLBACK;
With table files named after the table, we could not support the above,
because we'd need two "a"'s in existence at the same time. Postgres'
catalog mechanisms can handle rollback of the catalog changes, but the
Unix filesystem never heard of rollback :-(
There are other reasons, which some folks have pointed out elsewhere in
this thread, but that was the killer one.
I notice that MySQL seems to be migrating in this direction as well...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2003-04-17 15:19:26 | qualified column names |
Previous Message | Tom Lane | 2003-04-17 14:14:46 | Re: GLOBAL vs LOCAL temp tables |