Hacker News Reader

Comment by yxhuvud | Hacker News Reader

What really don't understand is why they chose mysql over postgresql - postgres already have hstore as a column type to store schemaless data. This includes support for indexes on the field.

View on HN

probably because as they stated they are familar with MySQL. After getting hurt trying out a new technology to them it makes sense they go back to something they know. Will probably lead to more uptime which is what they want.

We were excited to try a NoSQL db, having spent too many years using MySQL in ways that the designers of relational databases never imagined.

...

Given that we had experience with MySQL and knew it was adequate for our needs, it was hard to justify any other choice.

Agreed. It seems pretty clear from reading the article why they went with MySQL, which you wouldn't know from all of the Postgres butthurt in the comments.

Except they didn't choose mysql -- they chose Percona. Bonus of going with Percona is that in the process you get a fantastic company to back you up.

A "fantastic" company and a crappy database. Sounds like a questionable set of priorities.

I don't like MySQL either, but they're basically using it as a networked hash table. It's not so bad that it can't do that.

This is InnoDB's sweet spot really -- a mostly read-only in memory data set where the lookups are done primarily by PK. MySQL 5.5 can scale this kind of workload to 32 cores.

I'm pretty sure given this kind of workload MySQL will outperform PostgreSQL handily.

Why do you say this like it is impressive? Postgresql will scale to 32 cores with a real workload, and has done so for a few years. Mysql performance still tanks at 8 cores. It is very unlikely that mysql will be able to match postgresql for this workload, much less outperform it "handily".

Postgresql will scale to 32 cores with a real workload, and has done so for a few years. Mysql performance still tanks at 8 cores.

Both of those statements are not accurate, but hey, what's it matter? Without benchmarks we're both talking out our ass anyway.

The postgres part of the statement is accurate; http://rhaas.blogspot.de/2012/04/did-i-say-32-cores-how-abou...

No, it's not. The referenced article is talking about Postgres 9.2devel. Version 9.2 isn't out yet, and even if it was, it still wouldn't be true due to the clause "and has done so for a few years".

The lock manager bottlenecks that stopped PG from using more than 60% of the cpu power on a 24 core box were discovered a little less than a year ago.

http://rhaas.blogspot.com/2011/07/read-scaling-out-to-32-cor...

You are making assumptions about one scenario based on limitations encountered in a very different scenario. The problems that occur around 24 cores occur on benchmarks consisting entirely of select statements against a single table. As I said, postgresql has scaled to 32 cores for real workloads for a few years. Real workloads have more than one table.

See here for an example of mysql having problems at only 8 cores (and postgresql destroying mysql's performance): http://www.scribd.com/doc/551889/Introducing-Freebsd-70

Postgresql scaling to 28 cores in 2007: https://docs.google.com/viewer?a=v&q=cache:-ytn3fY_Lr8J:...

Postgresql on 32 core t2000 being able to scale up to 1024 concurrent clients in 2008: http://www.pgcon.org/2008/schedule/attachments/50_46_pgcon20...

Your MySQL example isn't exactly relevant. It was in 2007, yet you said "MySQL still tanks at 8 cores". Furthermore it was on FreeBSD, with a flawed libpthread.

In terms of "real" workloads, I'm not going to bother getting into it, as this is quickly devolving in to a true Scotsman argument.

Instead of arguing pointlessly about it, maybe our energy would be better spent publishing some benchmarks.

And PostgreSQL 9.2 will be able to scale this workload linearly to 64 cores. So while MySQL may or may not win it will certainly not "outperform PostgreSQL handily".

http://rhaas.blogspot.se/2012/04/did-i-say-32-cores-how-abou...

The key is that PostgreSQL 9.2 will be able to handle a 64 core workload, but current released versions of PG do not.

The fact is current versions of PG are unable to use more than 60% CPU on a 24 core machine. Do you know anyone who uses a dev version of an RDBMS in production?

http://archives.postgresql.org/message-id/BANLkTimVboKxzGS9B...

I believe that MySQL 5.5 scales to 32 cores but not linearly, while PostgreSQL 9.1 caps at 24 cores. As I said in my last comment: I do not doubt much that MySQL would beat PostgreSQL 9.1, but it wont beat it "handily".

Microsoft's Extensible Storage Engine (ESE) will also do an extremely fine job at this, and much more.

The author mentioned one of the reasons for choose MySQL is that they are familiar with MySQL. They could've went with PostgreSQL and EnterpriseDB, also a great company. It's not like you can't get commercial support with PostgreSQL.

Reply on news.ycombinator.com