From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | Scott Mead <scott(dot)lists(at)enterprisedb(dot)com>, 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-13 03:56:42 |
Message-ID: | 603c8f070912121956l7a634251yf6f544e828961875@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Fri, Dec 11, 2009 at 5:12 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> 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.
My development box at work is an 1.8 Ghz Celeron with 256K of CPU
cache, 1 GB of memory, and a single IDE drive... I don't have too
many slow queries in there.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-12-13 05:42:47 | Re: Winflex |
Previous Message | KaiGai Kohei | 2009-12-13 03:48:11 | Re: Largeobject Access Controls and pg_migrator |
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Carey | 2009-12-16 01:28:21 | Re: big select is resulting in a large amount of disk writing by kjournald |
Previous Message | Andres Freund | 2009-12-12 20:38:41 | Re: 8.4.1 ubuntu karmic slow createdb |