| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | sthomas(at)optionshouse(dot)com |
| Cc: | Craig James <cjames(at)emolecules(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Farina <daniel(at)heroku(dot)com>, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: DELETE vs TRUNCATE explanation |
| Date: | 2012-07-11 21:04:39 |
| Message-ID: | 4FFDEA67.6000801@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2012-07-11 21:20:28 | Re: Schema version management |
| Previous Message | Peter Eisentraut | 2012-07-11 21:04:19 | Re: pgsql_fdw in contrib |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Thornton | 2012-07-11 21:32:33 | Re: DELETE vs TRUNCATE explanation |
| Previous Message | Shaun Thomas | 2012-07-11 20:47:21 | Re: DELETE vs TRUNCATE explanation |