From: Scott Carey <scott@richrelevance.com>
To: Scott Marlowe <scott.marlowe@gmail.com>, Nikolas Everett
	<nik9000@gmail.com>
CC: "jd@commandprompt.com" <jd@commandprompt.com>, Andres Freund
	<andres@anarazel.de>, "pgsql-performance@postgresql.org"
	<pgsql-performance@postgresql.org>, Michael Clemmons
	<glassresistor@gmail.com>
Date: Fri, 11 Dec 2009 14:12:45 -0800
Subject: Re: 8.4.1 ubuntu karmic slow createdb
Thread-Topic: [PERFORM] 8.4.1 ubuntu karmic slow createdb
Thread-Index: Acp6rRSgY1s+l1aERIm0ov7X8f/t3AAAfv5v
Message-ID: <C74803DD.1B1BF%scott@richrelevance.com>
In-Reply-To: <dcc563d10912111357k538816baybbfdbe3b846f7aa3@mail.gmail.com>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 12/11/09 1:57 PM, "Scott Marlowe" <scott.marlowe@gmail.com> wrote:

>=20
> This is my big issue.  dropping / creating databases for unit tests is
> overkill.  Running any DDL at all for a unit test seems wrong to me
> too.  Insert a row if you need it, MAYBE.  Unit tests should work with
> a test database that HAS the structure and database already in place.
>=20
> What happens if your unit tests get lose in production and drop a
> database, or a table.  Not good.
>=20

Production should not have a db with the same username/pw combination as de=
v
boxes and unit tests . . .

Unfortunately, unit-like (often more than a 'unit') tests can't always rely
on a test db being already set up.  If one leaves any cruft around, it migh=
t
break later tests later on non-deterministically.  Automated tests that
insert data are absolutely required somewhere if the application inserts
data.

The best way to do this in postgres is to create a template database from
scratch with whatever DDL is needed at the start of the run, and then creat=
e
and drop db's as copies of that template per test or test suite.

So no, its not overkill at all IMO.  I do wish to avoid it, and ideally all
tests clean up after themselves, but in practice this does not happen and
results in hard to track down issues where test X fails because of somethin=
g
that any one of tests A to W did (all of which pass), often wasting time of
the most valuable developers -- those who know the majority of the system
well enough to track down such issues across the whole system.

One thing to consider, is putting this temp database in a RAMFS, or ramdisk
since postgres does a lot of file creates and fsyncs when cloning a db from
a template.  For almost all such test db's the actual data is small, but th=
e
# of tables is large.


> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org=
)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>=20