While the write up was good, the author makes assumptions about what's happening seemingly without checking.  He didn't post the actual query or the original and final query plans.<p>Partitioning is a rather complex solution to his problem. See the limitations at <a href="http://dev.mysql.com/doc/refman/5.1/en/partitioning-limitations.html" rel="nofollow">http://dev.mysql.com/doc/refman/5.1/en/partitioning-limitati...</a><p>I can't know for sure since there's not enough information there, but I'd suspect a simple index would have done the trick.<p><pre><code>  CREATE INDEX my_index ON Location (device_id, date_added desc)

  SELECT *
  FROM Locations USE INDEX (my_index)
  WHERE device_id = ...
  ORDER BY date_added DESC
  LIMIT 6

  SELECT *
  FROM Locations USE INDEX (my_index)
  WHERE device_id = ...
  AND date_added BETWEEN ... AND ...
  ORDER BY date_added DESC
</code></pre>
I'm assuming that he had the index and it just wasn't getting used, so the index hints are there in case the query planner was somehow missing them.<p>That said, table partitioning is an awesome feature. I've seen it be most useful when you spread the partitions over tiered storage (latest on SSD, archive on spindles), or when you want to drop a whole range of data quickly on a regular basis (like last month's logs).<p>* Edit: Missed something:<p>You may need to specify more hints than I originally thought if you want to force index usage for the order by clause as well.  See <a href="http://dev.mysql.com/doc/refman/5.1/en/index-hints.html" rel="nofollow">http://dev.mysql.com/doc/refman/5.1/en/index-hints.html</a>