Re: sql-bench
От | Merlin Moncure |
---|---|
Тема | Re: sql-bench |
Дата | |
Msg-id | b42b73150609131236y4132648csed2391b0b498f492@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: sql-bench (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: sql-bench
Re: sql-bench |
Список | pgsql-performance |
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
В списке pgsql-performance по дате отправления: