Ensure PG gives consistent benchmark results

When we added the 10k users to the database, even though the transaction
would never be committed, the query planner would still account for
them. This would mean that the max cost would continuously rise,
thinking there might be 100s of thousands of rows.

This led to `SELECT * FROM users` when the table was empty to take 70ms
to run (when even with 10k users it should be sub millisecond).
I'm not sure exactly what it was doing that was so slow, but if I had to
guess I'd say that it was probably allocating a lot more memory than it
needed to.

By truncating the table at the beginning of each transaction, we ensure
the query planner operates on 10k rows max, giving us consistent
results.

It should be noted that this isn't indicitive of any deeper flaw in the
framework. This gets cleaned up by the periodic vacuum that PG runs,
and in reality creating 10k rows in a transaction and then rolling back
multiple times per second is not realistic.

Author: sgrif

diesel_tests/tests/bench.rs

@@ -7,9 +7,21 @@ extern crate test;
 mod schema;
 
 use self::test::Bencher;
-use self::schema::*;
+use self::schema::{users, NewUser, User, Post, TestConnection, posts, batch_insert};
 use diesel::*;
 
+#[cfg(not(feature = "sqlite"))]
+fn connection() -> TestConnection {
+    let conn = schema::connection();
+    conn.execute("TRUNCATE TABLE USERS").unwrap();
+    conn
+}
+
+#[cfg(feature = "sqlite")]
+fn connection() -> TestConnection {
+    schema::connection()
+}
+
 #[bench]
 fn bench_selecting_0_rows_with_trivial_query(b: &mut Bencher) {
     let conn = connection();