On Fri, Dec 11, 2009 at 5:12 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > On Fri, Dec 11, 2009 at 2:59 PM, Scott Mead > <scott.lists@xxxxxxxxxxxxxxxx> wrote: >> On Fri, Dec 11, 2009 at 4:39 PM, Nikolas Everett <nik9000@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
