Re: DELETE vs TRUNCATE explanation - Mailing list pgsql-performance

From Jeff Janes
Subject Re: DELETE vs TRUNCATE explanation
Date
Msg-id CAMkU=1ydaypgAeZxyaMc=KhJJw5riGMBiLpvSqOO42=qArRZmQ@mail.gmail.com
Whole thread Raw
In response to Re: DELETE vs TRUNCATE explanation  (Daniel Farina <daniel@heroku.com>)
Responses Re: DELETE vs TRUNCATE explanation  ("Harold A. Giménez" <harold.gimenez@gmail.com>)
List pgsql-performance
On Wed, Jul 11, 2012 at 3:51 PM, Daniel Farina <daniel@heroku.com> wrote:
>
> Nope. I don't.  But an exact crossover is a level of precision I don't
> really need, because here are where things stand on a completely
> unremarkable test suite on the closest project to me that meets the
> "regular web-app" profile case:
>
> With en-masse DELETE:
> rake  41.89s user 3.08s system 76% cpu 58.629 total
>
> With TRUNCATE:
> rake  49.86s user 2.93s system 5% cpu 15:17.88 total
>
> 15x slower.  This is a Macbook Air with full disk encryption and SSD
> disk with fsync off, e.g. a very typical developer configuration.

What is shared_buffers?

> This is a rather small schema -- probably a half a dozen tables, and
> probably about a dozen indexes.  This application is entirely
> unremarkable in its test-database workload: it wants to load a few
> records, do a few things, and then clear those handful of records.

How many rounds of truncation does one rake do?  I.e. how many
truncations are occurring over the course of that 1 minute or 15
minutes?


Cheers,

Jeff

pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: how could select id=xx so slow?
Next
From: "Harold A. Giménez"
Date:
Subject: Re: DELETE vs TRUNCATE explanation