<?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>Alexander Kuznetsov : SQL</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL/default.aspx</link><description>Tags: SQL</description><dc:language>en</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>Override the optimizer or give it an easy task?</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/06/16/override-the-optimizer-or-give-it-an-easy-task.aspx</link><pubDate>Wed, 17 Jun 2009 02:43:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:14712</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>6</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/14712.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=14712</wfw:commentRss><description>When your query must always return in a certain amount of time, trusting the optimizer might not be the best choice. Suppose your select must return in one second no matter what, and it usually returns in 50 ms, but sometimes, once in 100K calls, it takes...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/06/16/override-the-optimizer-or-give-it-an-easy-task.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=14712" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL/default.aspx">SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/query+performance/default.aspx">query performance</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Index+Covering/default.aspx">Index Covering</category></item><item><title>When correlation between columns fools the optimizer</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/06/05/when-correlation-between-columns-fools-the-optimizer.aspx</link><pubDate>Fri, 05 Jun 2009 21:28:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:14482</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>4</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/14482.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=14482</wfw:commentRss><description>When two columns are correlated, it may fool the optimizer and cause it to choose a wrong plan. Here is a simple script that demonstrates it. The following script creates a table and populates some sample data: CREATE TABLE dbo.Vehicles ( ID INT NOT NULL...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/06/05/when-correlation-between-columns-fools-the-optimizer.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=14482" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL/default.aspx">SQL</category></item><item><title>Set based calculation of products of several numbers.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/03/17/set-based-calculation-of-products-of-several-numbers.aspx</link><pubDate>Tue, 17 Mar 2009 22:01:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:12714</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>10</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/12714.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=12714</wfw:commentRss><description>You can use SUM to calculate the sum of several numbers, but you cannot directly use set-based logic to calculate a product. Yet there is a very simple trick – you can use EXP(SUM(LOG(…))) and get a product of several numbers without a loop. The trick...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/03/17/set-based-calculation-of-products-of-several-numbers.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=12714" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL/default.aspx">SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Brainteasers/default.aspx">Brainteasers</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Set+based+logic/default.aspx">Set based logic</category></item><item><title>Defensive database programming: eliminating IF statements.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2008/11/27/defensive-database-programming-if-statement-vs-where-clause.aspx</link><pubDate>Thu, 27 Nov 2008 23:27:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:10149</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>29</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/10149.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=10149</wfw:commentRss><description>The following pattern is quite common in database programming: IF EXISTS(some query) BEGIN DO SOMETHING; END When such code runs in high concurrency situations, it may not work as expected. I will provide a repro when such logic fails 40% of the time....(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2008/11/27/defensive-database-programming-if-statement-vs-where-clause.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=10149" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL/default.aspx">SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Database+Programming/default.aspx">Database Programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Defensive+programming/default.aspx">Defensive programming</category></item><item><title>Performance of inserts and IGNORE_DUP_KEY</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2008/07/30/performance-of-inserts-and-ignore-dup-key.aspx</link><pubDate>Thu, 31 Jul 2008 02:39:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:8134</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/8134.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=8134</wfw:commentRss><description>If your data has a small percentage of duplicates, then IGNORE_DUP_KEY may speed up your inserts. For larger amounts of duplicates, IGNORE_DUP_KEY may slow them down significantly. I set up two tables, stripping down all the irrelevant details, as follows:...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2008/07/30/performance-of-inserts-and-ignore-dup-key.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=8134" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL/default.aspx">SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Database+Programming/default.aspx">Database Programming</category></item></channel></rss>