Hi John,

Does that mean that status_ids may not be unique across all users? For
example, one user could have status_id of 123 and another user can
have status_id of 123 so you have to uniquely identify them by their
user/status_id combination?

On Feb 11, 11:40 pm, John Kalucki <j...@twitter.com> wrote:
> In short, today, yes. Soon, no, but it might not matter.
> At the moment, status ids are strictly increasing. We can't keep generating
> status ids from a single critical section forever though -- at some point
> soon we'll have a loosely-coupled distributed id generation system and ids
> will be k-sorted. Perhaps the most significant bits will be monotonically
> increasing and the remainder of the precision will be opaque, and appear
> random. With any luck, the monotonically increasing precision will map,
> roughly, to time at a second resolution, so that the k-sorting will be
> within a second quantum. This would allow collation order based on the 1
> second created_at and a collation order based on the most significant bits
> will produce a similar, but not identical, ordering. Largely speculation.
> So, in the end, the date field remains the safest and the most future-proof
> way to sort statuses.
> -John Kaluckihttp://twitter.com/jkalucki
> Infrastructure, Twitter Inc.
> On Thu, Feb 11, 2010 at 2:36 AM, Quy <quyten...@gmail.com> wrote:
> > When I am sorting tweets, can I just do a simple sort DESC on
> > status_id instead of the creation date? I assume status_ids are
> > created sequentially going up so sorting on status_id would be more
> > efficient than trying to sort on the created_at field.

Reply via email to