Re: PostgreSQL vs MySQL, and FreeBSD

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@cheapcomplexdevices.com> wrote:
> Bill Moran wrote:
> > On Fri, 9 Nov 2007 11:11:18 -0500 (EST)
> > Greg Smith <gsmith@gregsmith.com> 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
>