From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jim(at)nasby(dot)net |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Growing Database Size |
Date: | 2003-06-16 13:40:09 |
Message-ID: | 2445.1055770809@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> On Sun, Jun 15, 2003 at 04:05:59PM +0530, Shridhar Daithankar wrote:
>> On 14 Jun 2003 at 13:50, Kenneth Godee wrote:
>> begin
>> drop table a;
>> drop table b;
>> create table a;
>> create table b;
>> copy -> table a;
>> copy ->table b;
>> commit;
>> vacuum analyze;
>> Hmm..Just wondering, will truncate in above steps would do the same job?
> Yes, truncate table would do the same job and more importantly, wouldn't
> go mucking about in the catalog tables. Assuming it's available in 7.2,
> you should absolutely use truncate instead of drop/create (man I wish
> more databases supported truncate).
However, the originally given sequence is transaction-safe (ie, on
failure it will roll back to the original state), whereas
something involving TRUNCATE will not be. Until 7.4 anyway.
Shridhar's drop/recreate is transaction-safe and looks like a good
solution if you're not worried about foreign key linkages and such.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-06-16 13:42:21 | Re: Why can't you define a table alias on an update? |
Previous Message | Greg Stark | 2003-06-16 13:26:02 | Re: full featured alter table? |