Add Memory Grants columns to sys.dm_exec_query_stats - by RobNicholson, MCSM

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<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 774334 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 12/13/2012 11:39:42 PM
Access Restriction Public


It would be really nice to be able to see the columns below in sys.dm_exec_query_stats.  

total_memory_grant, last_memory_grant, min_memory_grant, max_memory_grant

Currently there is no easy way to track memory grants except: shredding the XML of actual execution plans, comparing perfmon and profiler captures and Extended Events.  The problem with these methods is they must be configured beforehand or post-mortem (and wait to the problem occurs again).  Having these columns added to the dmv will allow the DBA to identify queries that ultilise high workspace memory.  From there the DBA could reduce these if necessary (preventing hash joins, sorts, etc).  
Sign in to post a comment.
Posted by RobNicholson, MCSM on 6/1/2015 at 8:19 PM
I see this has been added to SQL Server 2016, thank you.
Posted by Microsoft on 4/30/2013 at 1:02 PM

Thank you for submitting this feedback. After carefully evaluating all of the bugs in our pipeline, we are closing bugs that we will not fix in the current or future versions of SQL Server. The reasons for closing this bug is because the scenario reported in the bug are not common enough and due to the risk of implementing a fix it unfortunately does not meet the bar for the current version of the product.

If you have more supporting information and details or feel strongly that we should reconsider, please do resubmit this item for review.

Thanks again for reporting the product issue and continued support in improving our product.
Gus Apostol, SQL Server Program Manager
Posted by Vishal [MSFT] on 3/13/2013 at 4:27 PM
Thanks for the suggestion, we will triage this issue for future considration