Horton
Menu

Re: DELETE vs TRUNCATE explanation

Shaun Thomas <sthomas@optionshouse.com>

View thread
From: Shaun Thomas <sthomas@optionshouse.com>
To: Craig James <cjames@emolecules.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Daniel Farina <daniel@heroku.com>, Craig Ringer <ringerc@ringerc.id.au>, "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: 2012-07-11T20:47:21Z
Lists: pgsql-hackers, pgsql-performance 
On 07/11/2012 03:18 PM, Craig James wrote:

> It strikes me as a contrived case rather than a use case.  What sort of
> app repeatedly fills and truncates a small table thousands of times ...
> other than a test app to see whether you can do it or not?

Test systems. Any company with even a medium-size QA environment will 
have continuous integration systems that run unit tests on a trash 
database hundreds or thousands of times through the day. Aside from 
dropping/creating the database via template, which would be *really* 
slow, truncate is the easiest/fastest way to reset between tests.

If TRUNCATE suddenly started defaulting to DELETE on small table-sets 
and several iterations led to exponential index growth, that would be 
rather unfortunate.

-- 
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas@optionshouse.com



______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email

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.