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

Re: 8.4.1 ubuntu karmic slow createdb

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Scott Mead <scott(dot)lists(at)enterprisedb(dot)com>
Cc: Nikolas Everett <nik9000(at)gmail(dot)com>, jd <jd(at)commandprompt(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-performance <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 22:12:47
Message-ID: dcc563d10912111412j30b7c0d1n125e9d965053dfa3@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
On Fri, Dec 11, 2009 at 2:59 PM, Scott Mead
<scott(dot)lists(at)enterprisedb(dot)com> wrote:
> On Fri, Dec 11, 2009 at 4:39 PM, Nikolas Everett <nik9000(at)gmail(dot)com> wrote:
>>
>>
>>
>> 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.
>
>
>   The other common issue is that developers running with something like
> 'fsync=off' means that they have completely unrealistic expectations of the
> performance surrounding something.  If your developers see that when fsync
> is on, createdb takes x seconds vs. when it's off, then they'll know that
> basing their entire process on that probably isn't a good idea.  When
> developers think something is lightning, they tend to base lots of stuff on
> it, whether it's production ready or not.

Yeah, it's a huge mistake to give development super fast servers to
test on.  Keep in mind production may need to handle 10k requests a
minute / second whatever.  Developers cannot generate that kind of
load by just pointing and clicking.  Our main production is on a
cluster of 8 and 12 core machines with scads of memory and RAID-10
arrays all over the place.  Development gets a 4 core machine with 8G
ram and an 8 drive RAID-6.  It ain't slow, but it ain't really that
fast either.

In response to

Responses

pgsql-performance by date

Next:From: Scott MarloweDate: 2009-12-11 22:19:05
Subject: Re: 8.4.1 ubuntu karmic slow createdb
Previous:From: Scott CareyDate: 2009-12-11 22:12:45
Subject: Re: 8.4.1 ubuntu karmic slow createdb

pgsql-hackers by date

Next:From: Stephen FrostDate: 2009-12-11 22:18:17
Subject: Re: Adding support for SE-Linux security
Previous:From: Scott CareyDate: 2009-12-11 22:12:45
Subject: Re: 8.4.1 ubuntu karmic slow createdb

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