Yesterday, a coworker of mine was working on improving the performance of a report for one of our customers.

If a big enough period of time was selected, the report could take over a minute, which was totally unacceptable. In its previous form, the report was a big SQL query that returned the data almost ready to display it on screen. The query was taking a long time, and I asked him to take a look and see if he could improve the performance.

He started tweaking the SQL and gained important improvements, but it was still taking too long. So I suggested an idea where he could make a couple of much simpler queries, and join them on the client side. He didn’t seem to understand how those simple queries could get to the same result, so I asked if he understood what the report was supposed to show. He said that he had not taken a look at it yet, and was trying to improve on specific parts of the big SQL query.

I explained to him the expected results from the report. A couple of hours later, he had the report taking less than a second.

What’s the moral here? Always know about what you are ultimately trying to achieve. You may be able to fix a part of the current process (the big SQL query), but sometimes a totally new process is a better alternative (simpler queries with client-side processing). If you don’t know where you want to get in the end, you won’t be able to find alternate solutions.