Seems to me there is more thread model implementation problem on FreeBSD, and databases just reflecting it... Most of the test I done on Solaris show the same performance level on the same short READ-only queries for MySQL and PostgreSQL. And to be honest till the end, thread model should be far faster (context switching between threads is way faster vs processes), but - as I say usually - even a very good idea may be just wasted by a poor implementation... And in case of MySQL they have too much locking to manage concurrency between threads which kills all thread model benefits... Also, to compare apples to apples, they should run this test from remote client rather locally on the same host - however in this case the result for PostgreSQL will mostly depends on client implementation: if client implements reading via CURSOR (quite often), reading will generate 4x times more intensive network traffic than necessary and final PostgreSQL result will be worse... Reading this article I'm just happy for them to see progress done on FreeBSD :-) As well to demonstrate OS parallelism it's not so impressive to see 4CPU server results rather 8CPU or 32threaded Niagara... Don't know why they did not present similar performance graphs for these platform, strange no?... Rgds, -Dimitri On 11/9/07, Ron Mayer <rm_pg@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > Bill Moran wrote: > > On Fri, 9 Nov 2007 11:11:18 -0500 (EST) > > Greg Smith <gsmith@xxxxxxxxxxxxx> wrote: > >> On Fri, 9 Nov 2007, Sebastian Hennebrueder wrote: > >>> If the queries are complex, this is understable. > >> The queries used for this comparison are trivial. There's only one table > >> involved and there are no joins. It's testing very low-level aspects of > >> performance. > > > > Actually, what it's really showing is parallelism, and I've always > > expected PostgreSQL to come out on top in that arena. > > Isn't it showing Postgres winning even without parallelism. > > At 1 threads, Postgres looks like 800TPS where MysQL comes > in at about 600TPS on their Opteron charts. > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
