Re: Growing Database Size - Mailing list pgsql-general

From Tom Lane
Subject Re: Growing Database Size
Date
Msg-id 2445.1055770809@sss.pgh.pa.us
Whole thread Raw
In response to Re: Growing Database Size  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-general
"Jim C. Nasby" <jim@nasby.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

pgsql-general by date:

Previous
From: Greg Stark
Date:
Subject: Re: full featured alter table?
Next
From: Tom Lane
Date:
Subject: Re: Why can't you define a table alias on an update?