March 1, 2019 at 1:49 am
Hi,
My question is pretty is simple, its simply does SSMS recognise if a table is memory optimised or not?
The reason I ask is that I've run a query which uses both table types (disk and in memory) and looking at the execution plan SSMS is telling me I need a covering index on my memory optimised table (see screenshot).
These however are not supported, nor would it be needed as the index on there, currently on StatusID and StatusChange act as entry points to the data and contain all the other columns.
Is this just a case of SSMS getting a bit confused and thinking the table is disk based?
Thanks,
Nic
March 5, 2019 at 2:12 pm
NicHopper - Friday, March 1, 2019 1:49 AMHi,
My question is pretty is simple, its simply does SSMS recognise if a table is memory optimised or not?The reason I ask is that I've run a query which uses both table types (disk and in memory) and looking at the execution plan SSMS is telling me I need a covering index on my memory optimised table (see screenshot).
These however are not supported, nor would it be needed as the index on there, currently on StatusID and StatusChange act as entry points to the data and contain all the other columns.
Is this just a case of SSMS getting a bit confused and thinking the table is disk based?
Thanks,
Nic
I don't think it's SSMS, I think that's just the way it works - even with the DMV. The documentation for sys.dm_db_missing_index_details says to ignore included columns.
It wouldn't make sense to do so anyway with memory optimized tables.
sys.dm_db_missing_index_details
Sue
March 11, 2019 at 5:35 am
Thanks for the reply.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply