If all the systems have to do a table scan (complete scan of the data), then you're (almost always) I/O bound. Because we're relying on sequential I/O, a good hard disk is as good as a consumer-grade SSD. Postgresql doesn't do compression (if rows fit on a single page), and MySQL doesn't by default either (though you can enable InnoDB page compression), so if you're using compression with r17 you can get more rows per MB transferred, so you win.
However, this only works if you're doing table scans on highly compressible data. The minute you compete against an index, I suspect you're going to lose heavily (e.g. selecting the number of hits by second over a one minute interval should be very fast on the relational databases, as they should be able to answer from the index)
MySQL and PostgreSQL are really OLTP databases, but you're running an OLAP workload here (multi-minute queries and table scans are essentially the definition of OLAP). As you say, a comparison against Hadoop is probably more relevant (as long as you compress the data). For this workload, an OLAP database is the tool to beat, and Hadoop is probably the leading contender in the open-source OLAP space.
Though I'd normally bet on PostgreSQL, I think the easiest fix is to turn on Innodb compression in MySQL: you should see query times that are much more comparable. You'd probably still win (because MySQL is doing a lot more), but the margin should be much smaller.
I think it's also possible to denormalize your tables and improve your indexing, so that we can avoid table scans and then PostgreSQL/MySQL should be much faster, but I don't think this is really the point of your benchmark.
Edit: Just spotted a (much bigger) problem - if your data is 54GB raw, when compressed that should be within the memory size of your machine (12GB), but if MySQL and PostgreSQL aren't compressing their data won't fit into memory (particularly with all those unused indexes). So in fact you're comparing RAM speeds to SSD speeds, which really isn't apples to apples.