## Comment: Re:This merely allows poor code to suck less. (Score 3, Insightful) 174 174

From TFA, "*Maintaining those indexes is expensive and slows down transaction processing. Let's get rid of them," Ellison remarked. "Let's throw all of those analytic indexes away and replace the indexes with in-memory column sort."*
This merely minimizes the penalties of poor indexing and RBAR by making complete table scans on arbitrary columns faster. Apparently Mr. Ellison has forgotten his algoithmics and combinatorics - Oh, wait, no he didn't, he dropped out as a sophmore. Pity, because had he stayed, he would have learned that even with a 1000x slower storage medium, an O(log N) algorithm (index seek) will eventually beat an O(N log N) algorithm (column sort).

RTA - the improvement is there specifically for *real time analytic* workloads. In these kind of workflows the optimal algorithm is O(n) in general case and indexes are useless (query optimizing engine will always choose scans as you need to visit a lot of data). You might know a thing or two about algorithms, but you should brush up on problem analysis 101.

Other mistakes in logic: Index seek and column sort are not different algorithms for the same task so comparing them brings little insight (without considering some other details of the query optimizer). This leads you to nonsensical claim that O(log N) will *eventually* beat or be equal to O(N log N). It is not eventually, the first will be *always* faster or equal.