Groupby Free Sql Server Training

Have you ever considered a situation where Columnstore Index can be quite the opposite of what one would expect from it? A slow, wasteful source of painfully slow queries, lagging the performance, consuming irresponsible amount of resources ... Setting the wrong expectations (it won't run 100 times faster on EVERY query), selecting the wrong architecture (partition by 100s of rows instead of millions), using and aggregating by the large Strings in the fact tables - this list is actually quite large. What about some of the less known limitations for building Columnstore Indexes? The ones that will bite you suddenly in the middle of the project - when you do not expect it at all? Let me show you how to achieve those painful mistakes and you will surely know how to avoid them :)