Message-ID: <4FFDEA67.6000801@dunslane.net>
Date: Wed, 11 Jul 2012 17:04:39 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: sthomas@optionshouse.com
CC: Craig James <cjames@emolecules.com>, 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>
	<4FFDE659.7040104@optionshouse.com>
In-Reply-To: <4FFDE659.7040104@optionshouse.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 07/11/2012 04:47 PM, Shaun Thomas wrote:
> 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.


Why is recreating the test db from a (populated) template going to be 
slower than truncating all the tables and repopulating from an external 
source? I had a client who achieved a major improvement in speed and 
reduction in load by moving to this method of test db setup.

cheers

andrew