Skip site navigation (1) Skip section navigation (2)

Re: truncate vs. delete

From: Emi Lu <emilu(at)encs(dot)concordia(dot)ca>
To: "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com>, PostgreSQL SQL List <pgsql-sql(at)postgresql(dot)org>
Subject: Re: truncate vs. delete
Date: 2008-07-24 14:36:39
Message-ID: 48889377.7080804@encs.concordia.ca (view raw or flat)
Thread:
Lists: pgsql-sql
A. Kretschmer wrote:
> am  Thu, dem 24.07.2008, um 10:01:46 -0400 mailte Emi Lu folgendes:
>> A. Kretschmer wrote:
>>> am  Thu, dem 24.07.2008, um  9:47:48 -0400 mailte Emi Lu folgendes:
>>>> I found a link for SQL Server, it applies to PostgreSQL 8.0.x as well?
>>>> http://vadivel.blogspot.com/2004/06/delete-vs-truncate-statement.html
>>> Not realy, for instance, pg can rollback a truncate, and a sequence are
>>> not reset.
>>>
>>>
>> Thank you. I am quite sure that I will not use "delete" now.
>> Now I a question about how efficient between
>>
>> (1) truncate a big table (with 200, 000)
>>     vacuum it (optional?)
> 
> not required
> 
> 
>>     drop primary key
>>     load new data
>>     load primary ke
>>     vacuum it
> 
> analyse it, instead vacuum.

It gets more and more clear to me know!

I guess I need only do analyze(primary key column) after loading data.
The new picture will be:
. truncate table
. drop primary key
. load data
. set primary key
. analyze interesting columns










In response to

pgsql-sql by date

Next:From: Shane AmblerDate: 2008-07-24 14:38:58
Subject: Re: truncate vs. delete
Previous:From: Scott MarloweDate: 2008-07-24 14:33:12
Subject: Re: truncate vs. delete

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group