To add extra spice to their already broken organisation, Australia Post acquired StarTrack for parcel delivery.
I witnessed an operator in the distribution centre wait a solid thirty minutes for a key lookup in their database. I timed it with my phone. I had time to get get lunch and come back.
A key lookup. Literally the consignment number.
I grilled him a bit on the details, and it turns out that all single-row lookups take that much time. Name, phone number, or any other details all take about half an hour to produce a result.
There are parcel delivery services that can deliver door-to-door faster than their IT systems can look up a record.
It's a flabbergasting level of incompetence, but I'm told it's been like that for years, and that they were told not to fix it because during the merger they were to "put tools down" and not spend time and money on anything that Australia Post will fix anyway.
It's clearly just a missing index (or indexes) somewhere.
The guy explained that it has been "slowly getting worse" over many years, which is what you'd expect if there's table scans going on over a steadily growing volume of data.
IMHO, this is such as prevalent problem that it's the pandemic disease of SQL databases. They really should have indexing on by default for most columns, with the option of disabling unused indexes (perhaps even automatically).
Instead what happens is that 90-95% of all databases are 2-5 orders of magnitude slower than they ought to be, because developers are just unable to grasp these fundamental concepts. Developers haven't gotten any better at this over the last three decades. The tools have to get better to compensate instead.
PS: Almost all "no-SQL" databases are automatically or implicitly indexed. When people say that they're "much faster than SQL", I just assume that this is one of the biggest reasons. They're not inherently faster. Instead they're faster by default.
> They really should have indexing on by default for most columns, with the option of disabling unused indexes (perhaps even automatically).
Oracle does that. I think it is not enabled by default, but once you turn it on it's pretty much automated. It creates, rebuilds, and drops indexes based on the application workload.
There are third party tools for other databases (such as Dexter for PostgreSQL).
I witnessed an operator in the distribution centre wait a solid thirty minutes for a key lookup in their database. I timed it with my phone. I had time to get get lunch and come back.
A key lookup. Literally the consignment number.
I grilled him a bit on the details, and it turns out that all single-row lookups take that much time. Name, phone number, or any other details all take about half an hour to produce a result.
There are parcel delivery services that can deliver door-to-door faster than their IT systems can look up a record.
It's a flabbergasting level of incompetence, but I'm told it's been like that for years, and that they were told not to fix it because during the merger they were to "put tools down" and not spend time and money on anything that Australia Post will fix anyway.
I suspect it's still just as broken.