December 28, 2013 at 4:05 pm
Comments posted to this topic are about the item Memory-optimized table indexes in SQL 2014
December 28, 2013 at 4:07 pm
December 28, 2013 at 8:50 pm
Ron - I am happy that you learned something.
Diana
December 29, 2013 at 5:27 am
Nice question, thanks!
Regards,
IgorMi
Igor Micev,My blog: www.igormicev.com
December 29, 2013 at 7:04 am
I am really looking forward to memory optimized tables and indexes. I have been waiting for this for what seems like forever. 😉 Thanks for the question.
Steve
December 29, 2013 at 5:49 pm
IgorMi and Steve - You are welcome!
Diana
December 29, 2013 at 9:32 pm
Nice question. I found that thinking about it led me into all sorts of side tracks (which didn't stop after I'd reached an answer) some of which leave me quite confused and looking for more documentation - which is exactly the efect a question should have to maximise its boost to my learning about new things.
I wonder whether the structures used will introduce performance issues when row length is significantly shorter than the hardware cache line length - and if it will, does that matter. Obviously it doesn't matter much if scans in a particular order are rare and accesses to small clusters of adjacent records are also rare, and both of those conditions tend to be true in (most??) OLTP applications, and besides that it may be that cache line length is most often short enough to eliminate the issue, but was that part of the design philosophy here? The remark somewhere in the documentation that all indexes can be considered as covering seems to indicate that it was, but I don't recall seeing anything to that effect in early documentation on 2014. Actually I don't know what typical cache line lengths are on the processors windows runs on these days so it may be a complete non-issue.
Tom
December 29, 2013 at 9:33 pm
Nice question. I found that thinking about it led me into all sorts of side tracks (which didn't stop after I'd reached an answer) some of which leave me quite confused and looking for more documentation - which is exactly the efect a question should have to maximise its boost to my learning about new things.
I wonder whether the structures used will introduce performance issues when row length is significantly shorter than the hardware cache line length - and if it will, does that matter. Obviously it doesn't matter much if scans in a particular order are rare and accesses to small clusters of adjacent records are also rare, and both of those conditions tend to be true in (most??) OLTP applications, and besides that it may be that cache line length is most often short enough to eliminate the issue, but was that part of the design philosophy here? The remark somewhere in the documentation that all indexes can be considered as covering seems to indicate that it was, but I don't recall seeing anything to that effect in early documentation on 2014. Actually I don't know what typical cache line lengths are on the processors windows runs on these days so it may be a complete non-issue.
Tom
December 29, 2013 at 11:17 pm
Definitely learnt something new today, thanks Diana.
Hany
Thanks & Best Regards,
Hany Helmy
SQL Server Database Consultant
December 29, 2013 at 11:36 pm
Tom - What is the "hardware cache line length"? Do you know of a reference I can read about that?
Thanks
Diana
December 30, 2013 at 7:41 am
Thanks for the great question. I learned something today.
December 30, 2013 at 7:52 am
Thanks for the question. Interesting stuff, even if it will be 2020 before I get to use 2014 in a production environment.
I note that under "Index Count" it says:
Do not create an index that you rarely use
I would think that would be obvious. But, ...
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
December 30, 2013 at 8:54 am
Good question. They look like they have promise for limited applications, but it'll be quite a while until I get to use them, too.
December 30, 2013 at 9:05 am
Sent me scrambling for BOL... Thanks, Diana!
December 30, 2013 at 11:55 am
It took me a lot of time to find the correct answer for this one. I knew the two index types - but under different names ("hash" and "range"). Most seearches sent me to pages that used those same terms. Just as I was almost ready to give up, pick two, and see what the intended answer was, I stumbled upon the same page referenced in the explanation.
I'm already looking forward to seeing the final names of these features (and the number of name changes yet to come until release) 😉
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply