Re: [HACKERS] What can we learn from MySQL?
От | Alvar Freude |
---|---|
Тема | Re: [HACKERS] What can we learn from MySQL? |
Дата | |
Msg-id | 289880000.1082752989@gnarzelwicht.delirium-arts.de обсуждение исходный текст |
Ответ на | What can we learn from MySQL? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-advocacy |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, - -- Bruce Momjian <pgman@candle.pha.pa.us> wrote: > o Are we marketing ourselves properly? while talking about MySQL, there is the myth, that MySQL is fast; and that because MyISAM has no transactions, that it is faster. That is in most cases not true! And for all real live scenarios I know and I tested, Postgres was faster. An example: a critical calculation in one of my online projects needs with MySQL (MyISAM Table Type) about 2.7 to 2.8 seconds (group by on 500000 rows for some realtime statistics). But on this time, the complete table is write locked (because MyISAM) :-( With InnoDB the same needs at least 15 to 20 seconds, but other users can insert/update. With PostgreSQL (7.4) it took 1.9 to 2 seconds. Parallel inserts/updates no problem. The only reason why I changed the whole stuff to Postgres yet is, that there are a lot of problems with MySQL special "features" (see the Gotchas: http://sql-info.de/mysql/gotchas.html) Other example: Some days ago I had a talk with my project leader; I said, that for a new application we should *everything* build with transactions, referential integrity, ... -- his answer: "I want to have a fast application". AAARRGH! ;-( So, perhaps it might be a good idea to create a page with feature- and performance comparison. I planed to create an independant and RDBMS benchmark suite (as Free Software including the datas for testing), but I'm not sure if this project ever come true ... > o Are we focused enough on ease-of-use issues? I'm not sure about the focus; but the result can be better. When installing and using any type of software, I want that this is as easy as possible while it helps me to understand as much of the backgrounds as possible. Whats about the initdb, postgresql.conf and startup scripts? So, It might be good to have a GUI-Tool (!) in the standard package, which makes an initdb with selectable options and helps the user to set the required options in the postgresql.conf. I'm a computer freak since the mod 80s and I can edit config files. But to have a GUI tool with some explaining texts at the buttons etc is much easyer than hacking a textfile. Also the other stuff mentioned in this thread are important: auto vacuum, windows port, better default values etc. Ease-of-use includes for me localisation and documentation in different languages. As you can see, my english is junky -- so reading german documentation is a lot of easyer for me ;-) > o Are our priorities too technically driven? AFAIK it is good to have the priorities technically driven -- if nobody forgets the userfriendlyness ;) Ciao Alvar - -- ** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/ ** Berufsverbot? http://odem.org/aktuelles/staatsanwalt.de.html ** ODEM.org-Tour: http://tour.odem.org/ ** 5 Jahre Blaster: http://www.a-blast.de/ | http://www.a-blast.de/statistik/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAiX/eOndlH63J86wRAjzhAJ0f24+yuOSElI7NmFuChZUH3miWiACdFoH+ OLC0iUn7VP/ZIA30vU8M0tg= =RVWf -----END PGP SIGNATURE-----
В списке pgsql-advocacy по дате отправления: