He doesn't know what he's on about, but he likes MySQL.
You're putting words in my mouth that I didn't say. I don't like MySQL. I prefer PostgreSQL. And I have had a few rough times optimizing some queries in PostgreSQL, whereas I've had fewer such bad times with MySQL, despite using it more often. It's anecdata. Take it for what it's worth.
Time sinks in MySQL have come more from its crappy defaults, from its bizarre error handling (or lack thereof) in bulk imports, and most recently, a regression caused by a null pointer in the warning routine.
If I were working on my own project, I'd probably go with PostgreSQL and figure out the replication story. But I'm not. I do use PostrgeSQL on my personal projects.
(If there was one feature I'd add to PostgreSQL, it would be some means of temporarily and selectively disabling referential integrity. Not deferring it, not removing and readding foreign keys, just disabling. The app I work on does regular 10k-1M+ row bulk inserts, usually into a new table every time (10s of thousands of tables), but sometimes appending to an already 100M+ row table. It would be nice to have referential integrity outside of the bulk inserts, but not pay the cost on bulk insert.)
> Clearly implying that performance doesn't require a careful eye on MySQL
This is highly ironic, since you later say:
> you suck at logic
Funny chap!
(My point was that all the extra features in PostgreSQL give you more solution space, but not all of the solution space is suited to your problem. You have to watch out you're using the specific features in a way that pays off. Whereas MySQL is a bit like a hammer; you need to shape your problem like a nail, otherwise you won't be able to hit it at all. But when you do hit it, it mostly works. It's not a precision instrument though.)
>> makes it easy to do silly things, like turn off referential integrity in a slow query to boost performance.
> Which is really misleading, because it ships with most of that stuff off.
MySQL ships with referential integrity turned on - InnoDB is the default back end. Care to explain more?
(Personally, I wouldn't use MyISAM for my phone book, never mind in production.)
This comment reveals that you're utterly and completely ignorant. If you think InnoDB treats your data with respect by default, you've clearly never actually paid close attention to anything.
You're putting words in my mouth that I didn't say. I don't like MySQL. I prefer PostgreSQL. And I have had a few rough times optimizing some queries in PostgreSQL, whereas I've had fewer such bad times with MySQL, despite using it more often. It's anecdata. Take it for what it's worth.
Time sinks in MySQL have come more from its crappy defaults, from its bizarre error handling (or lack thereof) in bulk imports, and most recently, a regression caused by a null pointer in the warning routine.
If I were working on my own project, I'd probably go with PostgreSQL and figure out the replication story. But I'm not. I do use PostrgeSQL on my personal projects.
(If there was one feature I'd add to PostgreSQL, it would be some means of temporarily and selectively disabling referential integrity. Not deferring it, not removing and readding foreign keys, just disabling. The app I work on does regular 10k-1M+ row bulk inserts, usually into a new table every time (10s of thousands of tables), but sometimes appending to an already 100M+ row table. It would be nice to have referential integrity outside of the bulk inserts, but not pay the cost on bulk insert.)