Bart Duncan's SQL Weblog

Programmers should naturally gravitate toward the simplest, most elegant solution. This is because the simplest coding solution is so often the best solution: simple solutions are cheaper to implement; easier for others to understand, maintain, and extend; Read More...

In versions of SQL Server before SQL Server 2008, it can be difficult to determine the cumulative cost of the queries running on a server if the workload includes unparameterized queries. The only truly reliable method is to capture a Profiler trace during Read More...

Sometime we get complaints that a query is slower than it could be because a filter isn’t pushed very deeply down into a plan. For example, consider this hypothetical poor performance scenario (my apologies in advance for the lack of normalization): USE Read More...

To set up this scenario, run the script below: USE tempdb GO IF OBJECT_ID ('test1') IS NOT NULL DROP TABLE test1 GO CREATE TABLE test1 (c1 tinyint, c2 smallint) DECLARE @x int DECLARE @msg varchar(1000) SET @x = 1 SET NOCOUNT ON BEGIN TRAN WHILE (@x <= Read More...

Everyone that has worked with databases for long enough has run into situations where the query optimizer doesn't select the best possible plan. You may find that you can force SQL to use an index, choose a different join algorithm or join order, or use Read More...