Mechanism, not Policy
Over on Diamond Notes, a somewhat skeptical take on the recent Postgres benchmarks news. Can’t say I agree with it, and I did comment on it, but something did go click for me while thinking about it, hence this entry. See, the problem isn’t just performance. MySQL just doesn’t do the right thing.
I mean, I can understand the principle of implementing the smallest featureset you think a user would need and then optimising the bejaysus out of it – Epiphany would be a better browser than Firefox for 90% of the time for me because of that approach (it’s just Epiphany’s way of doing bookmarks that gets in the way) because Epiphany is always faster and less of a memory hog than Firefox since it doesn’t try to do everything. Emacs and vi is another example – sure emacs can do just about anything, but vi starts in a heartbeat and if you just want to add one line to your .muttrc/aliases, there’s not much point in firing up emacs. Of course, if you’re doing a chunk of work… but that’s another story.
The point was, before the digression, while MySQL was faster than Postgres in previous benchmarks, it wasn’t doing the job right. Sure, it was faster… but only if you wrote your SQL the MySQL way. Don’t use JOINs because MySQL doesn’t do those well. Yes, I know, there are better ways to do things than JOINs (and if you grok set theory, easier ways), but forcing end users to write SQL a certain way – and punishment with poor performance is forcing them – is the same as putting policy in the kernel. It violates one of the core tenets of unix kernel philosophy: Mechanism, not Policy.
There was also the point that MySQL didn’t really do SQL. I mean, transactions. Obvious example, I know, and everyone and her aunt has commented on it, so no need here beyond the usual “come on” response to the “oh, but you don’t need transactions” line. You might be right that there are other ways to do things, but guess what? That’s my choice as the developer, not yours. That’s the entire point to SQL – it lets me abstract away from the actual storage policy and just worry about the arrangement of the data in tables. In other words, it’s a Mechanism for me to implement my Policy with. And that’s a very powerful thing. But MySQL didn’t fully implement that Policy and it implements some parts of it more favorably than others, thus imposing it’s Policy on me through what’s meant to be an impartial Mechanism.
And yes, I know, Postgres adds to the SQL standard with its OO features. But that’s not the same thing. Adding to the standard is fine – so long as you implement the standard first.
So frankly, seeing Postgres doing so well in the performance benchmarks isn’t just a nice sight from the point of view of performance – it’s a nice sight from the point of view of doing the right thing. It means that the last thing that was holding back the better way of doing things has now been taken away. LAPP stacks? About time too!
Thanks for the comment on my blog. My point wasn’t Oracle vs mysql vs postgresql. I try my hardest to stay out of religious wars 🙂 My point is that it isn’t fair to perform any comparison test when the hardware isn’t the same. It skews the testing no matter what is running on top of it. I wouldn’t even consider running Oracle (and I was an Oracle DBA for a while back in the late ’90’s) so it really doesn’t matter one whit to me. It just boils my blood when companies sell this as some kind of test when it isn’t. It is running two databases on two different sets of hardware. That is all it is. And I don’t know who put this test together, but if it was one of the vendors and not some independent (and I do mean independent..not bought and paid for by one of vendors) testing entity I would consider that highly deceptive.
I know what you mean Keith, and I don’t disagree with it. To be fair, you have to admit there is the point of view of the vendors who’d consider the database and the hardware it’s running on as a single black box – but we both know that’s not a very good point of view 😀
Thing is I was more thinking about the way MySQL does things when I wrote this and not so much about the Oracle/Postgresql benchmark setup. It is definitely time someone set up a proper comparison benchmark between Postgres and MySQL though…
I’d say that comparing them all always comes down to the developer personal preference. They are products and they’re ruled by the same rules as any other products. They’ve been born because their was a requirement for them and then their users made them be different and then the competition changed them and will change them again so the differences between their capabilities will blur. The beauty of the process is that they will improve in every way to some point where they will meet the same SQL standard in the most efficient way but I seriously doubt that it would stop developers from „religious wars“ anyway, those war come from the natural human need to be accepted as part of the group/community and that will last as long as the human kind itself.
But that’s just my 5 cents. It’s a nice blog.
A great post put succinctly. It’s a point I’ve laboured for many years, which has for the most part fallen on deaf ears.
An excellent post, well done.