To view parent comment, click here.
To read all comments associated with this story, please click here.
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.






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!