Column Store Index, which improves performance of data warehouse queries several folds, was first introduced in SQL Server 2012. In this article series Arshad Ali talks about how you can get started with using enhanced columnstore index features in SQL Server 2014 and do some performance tests to understand the benefits.
2013-10-11
3,531 reads
Column Store Index, which improves performance of data warehouse queries several folds, was first introduced in SQL Server 2012. Unlike regular indexes or heaps, which store data in B-Tree structure (in row-wise fashion), the column store index stores data in columnar fashion and uses compression aggressively to reduce the disk I/O needed to serve the query request. In this article, Arshad Ali talks about the new enhanced columnstore index feature in SQL Server 2014.
2013-09-04
2,487 reads
The columnstore index in SQL Server 2012 stores columns instead of rows, and is designed to speed up analytical processing and data-warehouse queries. Whilst columnstore indexes certainly do that effectively, they are not a universal panacea since there are a number of limitations on them. When used appropriately, they can reduce disk I/O and use memory more efficiently.
2013-08-20
3,335 reads
2013-05-16
2,103 reads
It’s been forgotten about and neglected for few years but I’ve decided to dust...
I am honored to announce that I have been renewed as a Microsoft MVP...
By Rohit Garg
🔍 Demystifying KTLO: A Deep Dive into Keep The Lights On Work in IT...
Comments posted to this topic are about the item How a Legacy Logic Choked...
Comments posted to this topic are about the item Navigating Multi Platform Realities in...
I have tried a number of times to export and then import my SSMS...
For the Question of the day, I am going to go deep, but try to be more clear, as I feel like I didn't give enough info last time, leading folks to guess the wrong answer... :) For today's question: You’re troubleshooting a performance issue on a critical stored procedure. You notice that a previously efficient query now performs a full table scan instead of an index seek. Upon investigating, you find that an NVARCHAR parameter is being compared to a VARCHAR column in the WHERE clause. What is the most likely cause of the query plan regression?
See possible answers