Database Administrators, SQL Architects, Developers who writes queries, BI Devs working with ETL.
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 🙂
Why I Want to Present This Session:
I have seen people giving up on the Columnstore Indexes because they did not understood the internals and I would like to help people avoid those painful mistakes.
Latest posts by Niko Neugebauer (see all)
- Worst Practices & Less Known Limitations for Columnstore Indexes - December 13, 2016