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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
