Re: more anti-postgresql FUD

"Jacob Coby" <jcoby(at)listingbook(dot)com> writes:

> We were looking to improve our session performance, so I did a basic
> test of using mysql 4.0 innodb vs postgres 8.1. The test did a simple
> retrieve, update, save; 1 time per page. mysql was stock, pg had a
> shared_buffers and a couple of other standard tweaks done. ab was used
> to provide the load. server was an old dell pe2450 with 640mb of ram.
> tables were simple and a single primary key-foreign key relationship
> between them.
>
> pg was not only faster, it scaled to higher concurrency and had more
> predictable response times. mysql nosed over at around 5 concurrent
> connections. pg went to somewhere around 15.
>
> the more I read, the more it seems that mysql speed is a myth. it may
> be faster for simple flat-text sort of operations with one or two
> concurrent users where the app maintains RI, validates all data, and
> handles all of the complex joins. it just doesn't seem to scale up as
> well as pg.

I'm sorry but you tuned PG and not MySQL. This by itself makes that claim a
problem. If you used PG stock versys MySQL stock, then it would be more
valid. When comparing two things you have to give them the most fair
condition that is possible (i.e., either put two experts to tune both or use
both as shipped by their suppliers).

Perharps if PG was shipped with more aggressive defaults then we'd have a
different set of results (I doubt that a developer who optimizes his code for
MySQL and says that on his website will have read about optimizing PG and done
something like that).

Using PG's advanced features (specially triggers, functions and rules) will
make it MUCH better than having to deal with things at code level like a MySQL
optimized project will do...

--
Jorge Godoy <jgodoy(at)gmail(dot)com>