Message-ID: <4FFDE659.7040104@optionshouse.com>
Date: Wed, 11 Jul 2012 15:47:21 -0500
From: Shaun Thomas <sthomas@optionshouse.com>
Reply-To: <sthomas@optionshouse.com>
Organization: Peak6
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
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>
Subject: Re: DELETE vs TRUNCATE explanation
References: <4FFCCAC4.4030503@ringerc.id.au>
	<CAAZKuFZ9tYeC1K5ZayZgztm3re_7ytbsEYFa0wwXirB6Hfm+EQ@mail.gmail.com>
	<23853.1342015548@sss.pgh.pa.us>
	<CAFwQ8rcR5mimJO5FumcYzkgoxkNiP3g3XOaHB1H4oHe-QnLRPQ@mail.gmail.com>
In-Reply-To: 
 <CAFwQ8rcR5mimJO5FumcYzkgoxkNiP3g3XOaHB1H4oHe-QnLRPQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
content-transfer-encoding: 7bit

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