Skip site navigation (1) Skip section navigation (2)

Re: 8.4.1 ubuntu karmic slow createdb

From: Nikolas Everett <nik9000(at)gmail(dot)com>
To: jd(at)commandprompt(dot)com
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-performance(at)postgresql(dot)org, Michael Clemmons <glassresistor(at)gmail(dot)com>
Subject: Re: 8.4.1 ubuntu karmic slow createdb
Date: 2009-12-11 21:39:34
Message-ID: d4e11e980912111339q355f9fb2rf444f47a208b5b1e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
On Fri, Dec 11, 2009 at 3:50 PM, Joshua D. Drake <jd(at)commandprompt(dot)com>wrote:

> On Fri, 2009-12-11 at 15:43 -0500, Nikolas Everett wrote:
> > Turning fsync off on a dev database is a bad idea?  Sure you might
> > kill it and have to start over, but thats kind of the point in a dev
> > database.
>
> My experience is that bad dev practices turn into bad production
> practices, whether intentionally or not.
>

Fair enough.  I'm of the opinion that developers need to have their unit
tests run fast.  If they aren't fast then your just not going to test as
much as you should.  If your unit tests *have* to createdb then you have to
do whatever you have to do to get it fast.  It'd probably be better if unit
tests don't create databases or alter tables at all though.

Regardless of what is going on on your dev box you really should leave fsync
on on your continuous integration, integration test, and QA machines.
They're what your really modeling your production on anyway.

In response to

Responses

pgsql-performance by date

Next:From: Scott MarloweDate: 2009-12-11 21:57:56
Subject: Re: 8.4.1 ubuntu karmic slow createdb
Previous:From: Joshua D. DrakeDate: 2009-12-11 20:50:10
Subject: Re: 8.4.1 ubuntu karmic slow createdb

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-12-11 21:41:36
Subject: Re: Adding support for SE-Linux security
Previous:From: Robert HaasDate: 2009-12-11 21:34:42
Subject: Re: Adding support for SE-Linux security

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group