Search

Column Store Index should be read/write by AndrewTuerk

Closed
as Fixed Help for as Fixed

5
0
Sign in
to vote
Type: Suggestion
ID: 747788
Opened: 6/8/2012 3:01:55 PM
Access Restriction: Public
0
Workaround(s)
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.
Details (expand)

Product Language

English

Category

SQL Engine

Proposed Solution

allow for column store index to be writeable. preferable, clustered.

Primary Benefit

Improved Performance

Other Benefits

 

Virtualization

 
File Attachments
0 attachments
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).

Thanks,
Karl
Sign in to post a workaround.