Hacker News Reader

If the table is small enough that indexes aren't critical for reads, they probably don't impact the rate of writes either.

Of course, if the object is large scale bulk inserts, with only very occasional selects, then yes.

Wait a second, the whole thing is you don't mind O(N) overhead in searching on every request, but you mind O(log N) overhead for updates and inserts?

Well, my guess is that updates and inserts are much more frequent than searches in their use case. You're assuming a balanced frequency for these operations and it hardly ever happens.

This is a read-heavy workload per the OP: https://news.ycombinator.com/item?id=36071799

It was neither read-heavy nor write-heavy.

Ah, thanks for the correction; I’m guessing I read your comment too literally.

Would strikethrough my prior comment if it weren’t past the edit window…

My experience is that it's uaually better to add indices where it's expected to be needed beforehand. Adding indices on large production tables will millions of rows can bring down databases for hours or even days worst case. It's tricky to manage.

Considering how much data is written to support redo/undo/wal logs, a single index for user id is very little overhead.