I think the issue with multiple users is that a car is good for moving a few people, but it can't move lots of large boxes. A truck can move large boxes, but it can't move a few people efficiently. PostgreSQL is more like a truck, while MySQL is more like a car.
As an aside, I think Solaris is slower than other OS's because it is built to scale efficiently to many CPU's, and that takes a performance hit in a machine with just a few CPU's, though they are working on tuning those cases. Of course, this is all just a generalization. --------------------------------------------------------------------------- scott.marlowe wrote: > On Fri, 4 Jul 2003, Brian Tarbox wrote: > > > I'm actually leaving this list but I can answer this question. Our results > > were with a single user and we were running Inodb. We were running on > > RedHat 8.0 / 9.0 with vanilla linux settings. > > Hi Brian, I just wanted to add that if you aren't testing your setup for > multiple users, you are doing yourself a disservice. The performance of > your app with one user is somewhat interesting, the performance of the > system with a dozen or a hundred users is of paramount importance. > > A server that dies under heavy parallel load is useless, no matter how > fast it ran when tested for one user. Conversely, one would prefer a > server that was a little slow for single users but can hold up under load. > > When I first built my test box a few years ago, I tested postgresql / > apache / php at 100 or more parallel users. That's where things start > getting ugly, and you've got to test for it now, before you commit to a > platform. > > Postgresql is designed to work on anything out of the box, which means > it's not optimized for high performance, but for running on old Sparc 2s > with 128 meg of ram. If you're going to test it against MySQL, be fair to > yourself and performance tune them both before testing, they're > performance on vanilla linux with vanilla configuration tuning teachs you > little about how they'll behave in production on heavy iron. > > Good luck on your testing, and please, don't quit testing at the first > sign one or the other is faster, be throrough and complete, including > heavy parallel load testing with reads AND writes. Know the point at > which each system begins to fail / become unresponsive, and how they > behave in overload. > > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
