On Mon, Nov 8, 2010 at 10:47 PM, Sandeep Srinivasa <sss@xxxxxxxxxxxxxxx> wrote: > I did actually try to search for topics on multiple cores vs MySQL, but I > wasnt able to find anything of much use. Elsewhere (on Hacker News for > example), I have indeed come across statements that PG scales better on > multiple cores, which are usually offset by claims that MySQL is better. > Google isnt of much use for this either - while MySQL has several resources > talking about benchmarks/tuning on multi core servers > (e.g. http://dimitrik.free.fr/blog/archives/2010/09/mysql-performance-55-notes.html), > I cant find any such serious discussion on Postgresql Part of that is that 48 core machines with fast enough memory busses to use those cores, are only now coming out in affordable packages ($10k or so for a machine with a handful of drives) that they're just getting tested. I have 8 core, and 12 core older gen AMDs with DDR667 and DDR800 memory, and they dont' scale PAST 8 cores, either one, but that limitation is due more to the slower HT buss on the older AMDs. With the much faster HT busses on the 6xxx series Magny Cours CPUs they scale right out to 40+ cores or so, and give great numbers. The taper as you go past 48 processes isn't to bad. With proper pooling to keep the number of active connections at or below say 50, it should run well for a pretty huge load. And in everyday operation they are always responsive, even when things aren't going quite right otherwise. > However, what I did find > (http://www.pgcon.org/2008/schedule/events/72.en.html) was titled "Problems > with PostgreSQL on Multi-core Systems with Multi-Terabyte Data" > (interestingly, published by the Postgresql Performance Team @ Sun) We're not a company selling a product, we're enthusiasts racing our databases on the weekends, so to speak, and if someone has ideas on what's slow and how to make it faster we talk about it. :) That paper wasn't saying that postgresql is problematic at large levels so much as to address the problems that arise when you do, and ways to look forward to improving performance. > Ergo, my question still stands - maybe my google-fu was bad... why is why I > am asking for help. To know if either is a good choice you really need to say what you're planning on doing. If you're building a petabyte sized datawarehouse look at what yahoo did with a custom hacked version of pgsql. If you're gonna build another facebook look at what they did. They're both very different applications of a "database". So, your question needs more substance. What do you want to do with your db? -- To understand recursion, one must first understand recursion. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
