| Right... In case it helps to understand: compare it to something like weather models. You can't "just add indexes" to make it fast, but you can store the result of an hourly run and serve that to people in milliseconds. In my case, nobody's paying me to serve them that 'weather report' so it is what it is > Like I said then, you need indexes on those columns Dude, like I said ("that's not a correct assumption" in response to "It sounds like ... unindexed joins"), I have indexes on the relevant columns in the correct order Believe me I've benchmarked and SQL-EXPLAINed everything. All substantial queries have a code comment saying what index it uses as a way to make sure that changes to one query (and its corresponding index) don't affect another. I've learned a lot in this project about how everything from the different Where parts to the Order By clause to cardinality estimates to explicit index hints affect which indexes it can use as well as chooses to use. I enjoy learning about it, but now that I know the things relevant for this project, I'm also just done with the project and would rather spend my spare time on something new rather than adding code and introducing code and/or infrastructure complexity for storing parts of the computation that don't frequently change for example. Or if it was a popular site with frequent new visitors, that could be worth it as well. It's not. That doesn't make it necessarily a poor design if it's simply a lot of data > Search a table of 2.5 million records for a value is still blazing fast If you read what I write then you'd know it's not about looking up a single record |