Tom Harris web event on database improvements was one of the best events so far. There's amazing things being done with the database !
But ... towards the end of the session Tom was called to address query performance, specifically optimization in ABL vs OpenEdge SQL.
... with the usual apples-and-oranges routine, theres no need for query optimization in ABL.
Please stop ignoring, please stop dismissing these problems
"The SQL engine is faster then ABL" and "Who needs that feature ?" are 2 of my favorite answers
You need to be abit more careful around this topic. ABL queries are a real sensitive and sour point for us ABL'ers
ABL queries execution plan are pretty much static but, guys, queries are not static.
Applications might use the same query, same join order for completely different filters.
Take for example ABL reports and browser filters, there are no 2 filters a like.
Of course, that's as simple as it get, just to get the point across. The ABL query optimizer is seriously lacking and outdated.
It needs to be settled for once, set operations like UNIONS, GROUPING, ROLLUPS etc. are not compatible with ABL queries.
Query optimization is a shoe-in for ABL queries along with a long list of other common performance features.
The imporvements in OpenEdge SQL are great but they're mostly off limit to ABL.
That's not to say we don't benefit from them in external utils, reporting tools etc.
Of course things like query objects lack of BREAK BY make aggregates a real pain and CAN-FIND for things like EXISTS, IN etc.
ABL queries look like they're pretty much at a dead end. What improvements have been done since multiple indexes in V7 (wow, that was a long time ago) ?
We've got a great SQL engine, how about giving us access to it from ABL ? that could be directed to a temp-table or XML ?
Maybe even give us the option to make them ASYNCHRONOUS that could maybe address some of the issues with multi-threading ?
Every year there's this big festival around the latest benchmarks but me and some of my colleages sit back and think to ourselves, entertaining as they are, "who cares ?".
Those are not our day-to-day performance issues.
We've got state-of-the-art features to support transactions for multi-thousand users but we don't have the query features sometimes needed for 10 users and a million records.
We work with database applications what else takes time and needs to be improved on other then database access ?
If core features like these wouldn't have been so neglected there wouldn't be a need to convince users the language health is OK.