This will be much like we have for the ``jobs`` table.

Chatted in the meeting with emorley that perhaps this won't be necessary. Though, on further thought, I still think it is. Here's why: If we get a pulse message for a push id of 100, then get one for pushID 102, we will assume we missed 101. But our steps will be this: 1. Write the 102 we just got 2. schedule to fetch 101. 3. create 101 when we get it. Between step 2 and 3, a user may have fetched resultsets and gotten only 100 and 102, but not 101. When 101 comes in, the UI won't know to look for it. Fetching resultsets based on last_modified would fix this problem.

I will also need fields ``revision`` and ``vcs_push_id`` added to this table. I should probably add all these fields at once. These two fields should be populated by the etl layer and become (for now) optional fields in resultsets of the client.

I will add the ``revision`` field in another bug 1199364

Comment on attachment 8672161 [details] PR r=me, but left a comment

Commit pushed to master at https://github.com/mozilla/treeherder https://github.com/mozilla/treeherder/commit/a95b78dc65cd854eea4c5eecace0c91f7cb63518 Bug 1196804 - Add last_modified field to resultset table