Re: Delete operation VERY slow... - Mailing list pgsql-performance

From David Leangen
Subject Re: Delete operation VERY slow...
Date
Msg-id 1150445542.4812.34.camel@sonoda.bioscene.co.jp
Whole thread Raw
In response to Re: Delete operation VERY slow...  ("Gourish Singbal" <gourish@gmail.com>)
Responses Re: Delete operation VERY slow...  (PFC <lists@peufeu.com>)
Re: Delete operation VERY slow...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Wow! That was almost instantaneous. I can't believe the difference.

The only inconvenience is that I need to remove all the foreign key
constraints before truncating, then put them back after. But I suppose
it is a small price to pay for this incredible optimization.


Thank you!



On Fri, 2006-06-16 at 12:52 +0530, Gourish Singbal wrote:
>
> David,
>
> Truncate table would be a good idea if u want to delete all the data
> in the table.
> You need not perform vacuum in this case since there are no dead rows
> created.
>
> ~gourish
>
>
> On 6/16/06, David Leangen <postgres@leangen.net> wrote:
>
>         Hello!
>
>         I am trying to delete an entire table. There are about 41,000
>         rows in
>         the table (based on count(*)).
>
>         I am using the SQL comment: delete from table;
>
>         The operation seems to take in the order of hours, rather than
>         seconds
>         or minutes.
>
>         "Explain delete from table" gives me:
>
>                                   QUERY PLAN
>         ----------------------------------------------------------------
>         Seq Scan on table  (cost=0.00..3967.74 rows=115374 width=6)
>         (1 row)
>
>
>         I am using an Intel Pentium D 2.8GHz CPU. My system has about
>         1.2GB of
>         RAM. This should be ok... my database isn't that big, I think.
>
>
>         Any ideas why this takes so long and how I could speed this
>         up?
>
>         Or alternatively, is there a better way to delete all the
>         contents from
>         a table?
>
>
>         Thank you!
>
>
>
>         ---------------------------(end of
>         broadcast)---------------------------
>         TIP 5: don't forget to increase your free space map settings
>
>
>
> --
> Best,
> Gourish Singbal


pgsql-performance by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: SAN performance mystery
Next
From: Tim Allen
Date:
Subject: Re: SAN performance mystery