Slashdot Mirror
Revisiting FreeBSD vs. Linux for MySQL
Dan writes "Jeremy Zawodny, who looks after all of Yahoo!'s MySQL servers says MySQL now runs very well on FreeBSD. He is no longer steering people toward Linux. There are two important things you should do to make the FreeBSD/MySQL combo work well: (1) build MySQL with LinuxThreads rather than FreeBSD's native threads, and (2) use MySQL 4.x or newer."
Personally, I like using "cd /usr/ports/databases/postgresql7 && make install" rather than using a binary package, as that way you have the source code on your system, and you can use all of the wonderful things in the contrib directory.
tsearch is a very nice GIST indexed full text search that does word stemming.
reindexdb is a handy way to regenerate all of the indices in a database without interrupting anything.
earthdistance is far faster than writing the same thing as a SQL function.
ltree is wonderful when you have to deal with a hierarchy.
And those are just the ones I remember offhand...
Up to a point this is true. However MySQL does win on one point, namely that if you do not need most of the features of a real RDBMS then it is faster than Postgres. If you are just using it as an information store for a web site, for example, then it may be a better choice. As always, right tool for the right job.
I am TheRaven on Soylent News
And PostgreSQL is easier to work with. And setting up PgSQL is a breeze. And..
I could go on all day about why I don't use MySQL. Just because a great percentage of a particlar market is using something, it doesn't mean they are right. (viz: Microsoft products, on the whole, are a pain in the ass.)
Heute die Welt, morgen das Sonnensystem!
Please note that on 3.3-STABLE and -current, MySQL is also finally extremely stable on OpenBSD, with native threads.
A lot of threading-related work has been made during the 3.3 development cycle and there are no more unexpected crashes with this sort of apps. For instance the new threading code solved all issues I had with the Oops proxy, that is now very stable on production servers.
{{.sig}}
The article mentions that some things have been fixed in 5.0. Which could make some feel that upgrading to 5.0 would be a smart idea. However, FreeBSD hackers, being a conservative bunch, would disagree.
Thankfully, any worthwhile fixes in CURRENT will usually be backported to the STABLE. For example:
From the article:
The problem of MySQL occasionally thinking that all databases had vanished resulted from FreeBSD's non-threadsafe implementation of realpath().
CVS log for src/lib/libc/stdlib/realpath.c
MFC: make realpath thread-safe.
So personally me thinks a make world would be an idea sometime soon.
Do you mind, your karma has just run over my dogma.
Consider how you find the names of all the tables in a database:
On MySQL: SHOW TABLES
On Informix: SELECT tabname FROM systables
On PostgreSQL: SELECT relname FROM pg_class WHERE reltype='r'
Now if you hadn't known about the structure of pg_class beforehand and done considerable digging into the documentation, you'd be lost. A newbie even more so. Shouldn't something so simple be easy to do?
Or just \d (if you're using psql).
The problem is that, since people don't know the fundamentals of relational theory they don't know they don't need the 'features' (which in my mind, are a requirement).
This is why those of us that do know get flapped when those that don't tell us it is not necessary. See the problem?
Thanks,
--
Matt
and let's not forget VACUUMDB.
Want to claim back all this space lost when you deleted something? guess what, you'll have to lock your database. greeeaaat.
And it's so sloooooooow that now i have to dump/restore the DB every week.
And don't even mention database replication: you can do that on mySQL (with the logs), while the postgreSQL team is still struggling with this one.
i had a sig, once..