On Fri, Dec 11, 2009 at 2:59 PM, Scott Mead <scott.li...@enterprisedb.com> wrote: > On Fri, Dec 11, 2009 at 4:39 PM, Nikolas Everett <nik9...@gmail.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. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
