Chis Browne wrote:
> PostgreSQL is likely to be way slower if you submit streams of little
> queries, each an independent transaction...
When I get around to it I plan on debunking this ;). I recently did
extensive internal benchmarking of mysql 5.0 vs. postgresql 8.1 and
it's victories across the board with only a couple of exceptions, and
I have benchmarks to prove it. Im summary:
1. mysql is faster when it's query cache hit ratio is high
2. mysql opens connections much faster than pg, which is why we use pgpool
3. mysql sometimes wins where mvcc delete + insert can be kind of a
pain (*much* rarer than commonly thought)
While 'out of the box' postgresql is slower at select a,b,c from t
where k type queries wrt mysql, the performance advantage is
completely negated if you run those queries via prepared statements.
In postgresql, queries executed over the parameterized/prepared C api
are particularly fast...as much as a 70% speed reduction over vanilla
PQexec. Now, the lower level API and prepared statements are not
available for all applications, but when used they provide extremely
low-latency access.
Also,
1. pg can read off large result sets (50k records +) from the cache
much faster than mysql
2. pg has a generally better query optimizer, altough here and there
mysql scores a win
3. many other advantages you are already quite familiar with, mvcc, etc.
Basically, I am saying that the proverbial bread and butter queries
are not necessarily faster on mysql, just easier to get running fast,
if that makes sense. Now, I'm not trying to bash mysql (I was in
fact, quite impressed with 5.0) generally, but I really think the
claim that it is faster for a broad array of tasks is highly dubious.
pg just requires a little bit more specialized knowledge to get
running up to its level in some cases.
Merlin