On 9/13/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> IIRC, with these settings PG 8.0 seemed to be about half the speed of
> mysql 5.0 w/myisam, which is probably somewhere in the ballpark of the
> truth for tests of this nature, ie, single query stream of fairly simple
> queries. If you try concurrent-update scenarios or something that
> stresses planning ability you may arrive at different results though.
> I have not retested with more recent versions.
if postgresql uses prepared statements for such queries, it will
roughly tie mysql/myisam in raw query output on this type of load
which also happens to be very easy to prepare...afaik mysql gets zero
performance benefit from preparing statements This is extremely
trivial to test&confirm even on a shell script. [aside: will this
still be the case if peter e's planner changes become reality?]
another cheater trick benchmarkers do to disparage postgresql is to
not run analyze intentionally. Basically all production postgresql
systems of any size will run analyze on cron.
another small aside, I caught the sqlite people actually *detuning*
postgresql for performance by turning stats_command_string=on in
postgresql.conf. The way it was portrayed it almost looked like
cheating. I busted them on it (go to
http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison and look for the
remarks right below the results)
merlin