Horton
Menu

Re: DELETE vs TRUNCATE explanation

Jeff Janes <jeff.janes@gmail.com>

View thread
From: Jeff Janes <jeff.janes@gmail.com>
To: Harold A. Giménez <harold.gimenez@gmail.com>
Cc: Daniel Farina <daniel@heroku.com>, Tom Lane <tgl@sss.pgh.pa.us>, Craig Ringer <ringerc@ringerc.id.au>, "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: 2012-08-09T18:06:54Z
Lists: pgsql-hackers, pgsql-performance 
On Thu, Jul 12, 2012 at 4:21 PM, Harold A. Giménez
<harold.gimenez@gmail.com> wrote:
> Hi,
>
> I work with Daniel Farina and was the other engineer who "discovered" this,
> once again. That is, I got bit by it and have been running TRUNCATE on my
> test suites for years.

Hi Daniel and Harold,

I don't know if you followed this thread over into the -hacker mailing list.

There was some bookkeeping code that was N^2 in the number of
truncations performed during any given checkpoint cycle.  That has
been fixed in 9.2Beta3.

I suspect that this was the root cause of the problem you encountered.

If you are in a position to retest using 9.2Beta3
(http://www.postgresql.org/about/news/1405/), I'd be interested to
know if it does make truncations comparable in speed to unqualified
deletes.

Thanks,

Jeff

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Scan the buffer pool just once, not once per fork, during relation drop.