<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://sqlblog.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Search results matching tags 'SSMS', 'functions', 'execution plan', and 'plan cache'</title><link>http://sqlblog.com/search/SearchResults.aspx?o=DateDescending&amp;tag=SSMS,functions,execution+plan,plan+cache&amp;orTags=0</link><description>Search results matching tags 'SSMS', 'functions', 'execution plan', and 'plan cache'</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>Connect Digest : 2010-01-22</title><link>http://sqlblog.com/blogs/aaron_bertrand/archive/2010/01/22/connect-digest-2010-01-22.aspx</link><pubDate>Fri, 22 Jan 2010 19:47:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:21360</guid><dc:creator>AaronBertrand</dc:creator><description>&lt;p&gt;&lt;font size="3"&gt;&lt;b&gt;Give us easier to read execution plans&lt;/b&gt;&lt;/font&gt;&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;Michelle Ufford (&lt;a href="http://twitter.com/SQLFool" title="http://twitter.com/SQLFool" target="_blank"&gt;@SQLFool&lt;/a&gt;) recently asked for help pinpointing the most expensive node(s) in a complicated execution plan.&amp;nbsp; Mladen Prajdic (&lt;a href="http://twitter.com/MladenPrajdic" title="http://twitter.com/MladenPrajdic" target="_blank"&gt;@MladenPrajdic&lt;/a&gt;) has a useful workaround; he coded up a &lt;a href="http://weblogs.sqlteam.com/mladenp/archive/2010/01/21/SQL-Server-ndash-Find-the-most-expensive-operations-in-Execution.aspx%20" title="http://weblogs.sqlteam.com/mladenp/archive/2010/01/21/SQL-Server-ndash-Find-the-most-expensive-operations-in-Execution.aspx " target="_blank"&gt;quick query to parse the showplan XML&lt;/a&gt; and order results by cost descending.&amp;nbsp; The Connect item that would make this workaround unnecessary was filed by "Ewan1": &lt;br&gt;
&lt;/p&gt;&lt;/blockquote&gt;&lt;blockquote&gt;&lt;p&gt;&lt;a href="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=477390" title="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=477390" target="_blank"&gt;#477390 : Rank cost of graphical execution plan components in SSMS&lt;/a&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;&lt;b&gt;&lt;font size="3"&gt;&lt;br&gt;Give us more SARG intelligence in the optimizer &lt;/font&gt;&lt;/b&gt;&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;As Adam Machanic (&lt;a href="http://twitter.com/AdamMachanic" title="http://twitter.com/AdamMachanic" target="_blank"&gt;@AdamMachanic&lt;/a&gt;) lays out &lt;a href="http://sqlblog.com/blogs/adam_machanic/archive/2009/10/20/what-happened-today-date-and-date-ranges-over-datetime.aspx" title="http://sqlblog.com/blogs/adam_machanic/archive/2009/10/20/what-happened-today-date-and-date-ranges-over-datetime.aspx" target="_blank"&gt;in a recent blog post&lt;/a&gt;, the optimizer is getting better at this with each new version, but in this Connect item, Rob Farley (&lt;a href="http://twitter.com/rob_farley" title="http://twitter.com/rob_farley" target="_blank"&gt;@Rob_Farley&lt;/a&gt;) correctly points out that there are a lot of places where non-sargable arguments could obviously (and automatically) be made sargable. &lt;br&gt;
&lt;/p&gt;&lt;/blockquote&gt;&lt;blockquote&gt;&lt;p&gt;&lt;a href="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=526431" title="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=526431" target="_blank"&gt;#526431 : Make more functions SARGable&lt;/a&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;br&gt;&lt;font size="3"&gt;&lt;b&gt;Give us more Agent smarts : system procedures to avoid ad hoc queries &lt;/b&gt;&lt;/font&gt;&lt;br&gt;&lt;blockquote&gt;&lt;p&gt;Dave Ballantyne (&lt;a href="http://twitter.com/DaveBally" title="http://twitter.com/DaveBally" target="_blank"&gt;@DaveBally&lt;/a&gt;) &lt;a href="http://sqlblogcasts.com/blogs/sqlandthelike/archive/2010/01/22/microsoft-follow-best-practices.aspx" title="http://sqlblogcasts.com/blogs/sqlandthelike/archive/2010/01/22/microsoft-follow-best-practices.aspx" target="_blank"&gt;blogged&lt;/a&gt; that SQL Agent is still very stubborn about submitting ad hoc queries all day long when, in reality, there should be a whole bunch of procedures in msdb to satisfy these queries (and prevent unnecessary ad hoc cache bloat)&amp;nbsp; He also filed this Connect item: &lt;/p&gt;&lt;/blockquote&gt;&lt;blockquote&gt;&lt;p&gt;&lt;a href="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=526485" title="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=526485" target="_blank"&gt;#526485 : dm_exec_cached_plans Bloat&lt;/a&gt; &lt;br&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;&amp;nbsp;&lt;b&gt;&lt;font size="3"&gt;&lt;br&gt;Give us more power to work with data in the results pane&lt;/font&gt;&lt;/b&gt;&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;After some back-and-forth with Buck Woody (&lt;a href="http://twitter.com/BuckWoody" title="http://twitter.com/BuckWoody" target="_blank"&gt;@BuckWoody&lt;/a&gt;), I filed this suggestion, which asks for the ability to embed Excel in the results pane of Management Studio.&amp;nbsp; This would allow us much more immediate analysis of results, with fewer steps.&lt;/p&gt;&lt;/blockquote&gt;&lt;blockquote&gt;&lt;p&gt;&lt;a href="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=524769" title="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=524769" target="_blank"&gt;#524769 : SSMS : Ability to embed Excel in results pane&lt;/a&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;&amp;nbsp;&lt;font size="3"&gt;&lt;b&gt;&lt;br&gt;Give us better error messages &lt;/b&gt;&lt;/font&gt;&lt;br&gt;&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;Since I work with multiple schemas, I am coming across more and more error messages from the engine that were obviously written at a time when everything was owned by dbo.&amp;nbsp; As the product gets more complex and the schema model takes hold, this will need to be corrected.&lt;/p&gt;&lt;/blockquote&gt;&lt;blockquote&gt;&lt;p&gt;&lt;a href="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=525308" title="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=525308" target="_blank"&gt;#525308 : All error messages that include object name need to also include schema name&lt;/a&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;&lt;br&gt;&lt;font size="3"&gt;&lt;b&gt;Give us more predictable function performance &lt;/b&gt;&lt;/font&gt;&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;Simon Sabin (&lt;a href="http://twitter.com/Simon_sabin" title="http://twitter.com/Simon_sabin" target="_blank"&gt;@Simon_Sabin&lt;/a&gt;) and Andrew Novick had similar suggestions: to finally fix the abysmal performance of UDFs that has been present since they were first introduced to the product.&lt;br&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;blockquote&gt;&lt;p&gt;&lt;a href="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=524983" title="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=524983" target="_blank"&gt;#524983 : User defined function performance is unacceptable&lt;/a&gt; &lt;br&gt;&lt;/p&gt;&lt;a href="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=273443" title="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=273443" target="_blank"&gt;#273443 : The Scalar Expression function would speed performance while keeping the benefits of functions&lt;/a&gt;&lt;/blockquote&gt;&lt;p&gt;&lt;br&gt;&lt;font size="3"&gt;&lt;b&gt;Give us more complete metadata about stored procedures&lt;/b&gt;&lt;/font&gt;&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;Greg Low (&lt;a href="http://twitter.com/GregLow" title="http://twitter.com/GregLow" target="_blank"&gt;@GregLow&lt;/a&gt;) came up with an interesting suggestion about providing better metadata about stored procedures (a "contract").&amp;nbsp; I don't agree with all of Greg's ideas (see recent threads &lt;a href="http://sqlblog.com/blogs/greg_low/archive/2010/01/19/stored-procedures-time-for-a-real-contract.aspx" title="http://sqlblog.com/blogs/greg_low/archive/2010/01/19/stored-procedures-time-for-a-real-contract.aspx" target="_blank"&gt;here&lt;/a&gt; and &lt;a href="http://sqlblog.com/blogs/greg_low/archive/2010/01/20/stored-procedure-contracts-return-values.aspx" title="http://sqlblog.com/blogs/greg_low/archive/2010/01/20/stored-procedure-contracts-return-values.aspx" target="_blank"&gt;here&lt;/a&gt;),
but in general I agree that the metadata for stored procedure
interfaces could be exposed better - providing benefits all around, but especially in
environments where a consistent standard is enforced (e.g. resultset shape is not only deterministic but also remains consistent even when inputs do change).&lt;/p&gt;&lt;/blockquote&gt;&lt;blockquote&gt;&lt;a href="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=525653" title="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=525653" target="_blank"&gt;#525653 : Stored procedures should expose detailed contracts&lt;/a&gt;&lt;/blockquote&gt;</description></item></channel></rss>