Bad indexing, no indexing, and fragmented indexes seem to cause no end of issues, and there always seem to be shortages of people capable of fixing it properly.
They’re out there—but I just ran EXPLAIN ANALYZE on my company’s search for them, and the query planner’s not too happy. It has to scan the entire resume heap before doing an on-site join with candidates, all while dealing with resource contention from queries of other employers. I know recruiters and e.g. triplebyte, stackoverflow all offer indexes to speed up this search, but in our case those indexes wouldn’t fit in cash.
Why does the index need to fit in "cash" (cache RAM)? Generally an index on disk, especially SSD, is far faster than traversing the entire dataset, because it allows the query executor to quickly narrow it down. Even if this requires some disk IO, it's a lot faster than doing all the disk IO for the entire dataset.
I'm not sure if you missed the joke (he basically was saying "It's hard to hire people who can do this sort of thing; they're out there but in demand and recruiters are expensive" but using DB terminology) and are thinking he's actually describing a DB operation, or if you're building on it so obliquely -I- am missing the joke you're trying to make.
That was very very good, but I wonder what sort of latency you experienced on the query that produced that result.
In order to fix a problem, one must be able to first identify the problem. Many people are still unaware of how indexing works, even though the devices they utilize daily perform this action routinely.
not to mention ORMs that query a lot of data through non ideal joins.