Linked by Thom Holwerda on Wed 18th Oct 2006 16:58 UTC, submitted by wirespot
Databases The popular MySQL database is slated for a future split between what MySQL AB calls the Community and the Enterprise versions. Read the official announcement and further opinions and explanations from Kaj Arno (MySQL VP of Community Relations) and Stephen O'Grady (software industry analist). In Arno's own words: "We recognise that the needs of the MySQL Community are different from the needs of commercial enterprise customers. After 11 years of producing our software, we can no longer hope that a single offering is the best solution for both Community and Enterprise users. Consequently, we are introducing two different offerings for each distinct target group."
Thread beginning with comment 172808
To view parent comment, click here.
To read all comments associated with this story, please click here.
justinbest
Member since:
2006-06-29

Thanks for the advice. No, it's not the "buzz" that I want. My project is a small, in-house data analysis tool written by me, for me. I'm tired of dealing with the quirks of PG (vacuuming all the time, lack of easy-to-set-up performance monitors, etc.)

It could just be my lack of knowledge, but enforcing data integrity with anything over 300,000 rows in my table seems to cause more hassle than help. Performance grinds to a halt with all those internal consistency checks. I didn't experience performance issues back before I rewrote the project to use PG (I used MySQL previously).

So, even though I know I will have to do some extra work client-side, I think the tradeoff will be worth it. We'll see if I ever have the spare time to find out, though!

Reply Parent Score: 2

nathan_c Member since:
2005-07-12

I've used both extensively over the last few years, and they have their benefits. However, before you jump ship from PG->MySQL, here are my recommendations that have helped me with performance issues on PG:

1. If you are using pg7.x, upgrade to the 8.x. It's amazing how many people use older versions (me included) and there's just so much neat stuff in the latest.

2. MySQL is a lot more forgiving of bad/misconfigured databases. Take the time (if you haven't done so) to really index the database well, watch the execution plans (pgadmin has a visual plan analyzer) and see if you can rewrite your poorly performing or most-used queries in a different way. We went from a slow web application (several seconds per some queries) to a very fast app by spending the time to optimize our queries and indices. The same is true for the server config itself. Make sure you understand and set up the configuration properly for the dataset you are anticipating.

3. If this doesn't help and MySQL performs better - make the move. I'm just trying to save you the pain of a migration with some suggestions.

Reply Parent Score: 3