Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"We can replace the timestamp with the primary key for the “recentness” calculation". Very different properties, not a great replacement.


I definitely agree that there may be some unexpected consequences of using the primary key in this way. It certainly won't behave like a timestamp and could distort the function outputs.

Would it be possible to substitute the integer count of seconds since epoch (or some other arbitrary base timestamp) and use that instead? Then you'd still have an immutable function to satisfy the index, but also you'd preserve valuable information about the relative time intervals between posts.


Yeah. If you wanted to delay making posts visible but create them in advance, they wouldn't have the same ranking as though they were just posted. You'd have to create them at the exact time you'd want them to start being displayed in order for the desired ranking to be correct.


The example was a social media site like Instagram, not a blog, which doesn't allow future posting. If you have different design constraints than the given example, obviously the implementation will need to adjusted to the new requirements.


No problem, just add a bot that creates a post every second, so that the pace of the primary key approximates that of the timestamp. /s


Care to expand on that?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: