Column Store Index should be read/write - by AndrewTuerk

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 747788 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 6/8/2012 3:01:55 PM
Access Restriction Public


While useful in warehousing scenarios and read only workloads, the primary capacity in which i would like to use a column store index is in a read/write scenario.  I do not have the luxury (in most cases) of being able to have async updates.  Thus, a read only index is not useful outside of warehousing scenarios.  I do, however, have cases where the data i would index in a column or group of columns is highly duplicated.  for example, in one table i have 5 columns, 100,000,000 records.  distinct records per column:

column a - 1,000,000
column b - 12,000
column c - 3
column d - 50
column e - 3,000,000

Due to varying access patterns, there are multiple indexes on this table.  Read/Write is about 20:1.  In my particular case, i believe it would also be beneficial if i could have a writable clustered column store index.  Enforcing uniqueness as a row based concept is still important on this table.
Sign in to post a comment.
Posted by Microsoft on 2/20/2013 at 3:02 PM
This is implemented and will be released soon.
Posted by Karl He on 1/5/2013 at 7:15 PM
Vote for this. It may be hard to completely support random writes but column store index will be much easier to use if it becomes 'a bit more writable'. For example, the first step can be to support 'append operation' that doesn't change exsisting rows, or at least enable user to explicitly indicate 'which part has been appended, please incrementally rebuild'. Not sure how difficult it is under the cover but it really helps a lot in real world scenarios (I know some work around at the moment but they are just too cumbersome).