4 ms·
To some degree, this looks like premature optimization. That query (on the normalized tables), with the proper indexes and decent hardware, should be plenty fas
by briHass 10y ago
To some degree, this looks like premature optimization. That query (on the normalized tables), with the proper indexes and decent hardware, should be plenty fast, even with millions of rows. I would potentially start my optimization by considering if messages could be 'archived' to other tables or considering how long I could cache the query results vs. how often the client would poll.
I've seen small-medium sized systems go way overboard with complicated mechanisms for handling performance problems that they don't, and may never, have.
- jerf 10y agoYou have to grant blog posts about issues that only appear at scale a certain amount of leeway with their examples. In the wild, if you're writing normalized schemas, traversing 5 tables isn't that difficult and traversing a couple dozen comes up more often than you'd like. It's not hard to run past what a query optimizer can handle.
- sixdimensional 10y agoSo I agree, premature optimization can often not be necessary. But let's be crazy for a minute. How much CPU/RAM/disk IO does that query on normalized tables end up using? How much electricity does that query use? Maybe from a pure efficiency perspective, it takes less energy to query the pre-computed value, than to constantly be recalculating it on every query.
- quickben 10y agoCraziness comes later. Usually few years after several developers added not normalized tables, and it all grew organically with multiple apps depending on the data. When it comes to rdbms shema, you want it optimized and enforced from day one, or the price paid later will be significant.