The “Tally table” is a well-known concept not only in the SQL Server world but in all set-based (relational) database engines. I don’t want to repeat some basic or go much deep into it. You can do it on your own starting i.g. on sqlservercentral.com. My post is just another reminder of why it’s really good to go with Tally table instead of row-by-row direction. And yes, it’s about the performance as usual. Let’s start the game.

Our mission is simple: We would like to generate a simple calendar table with one date (day) per row for all dates between @StartDate and @EndDate. We will use the WHILE loop and add one day to the @StartDate on each cycle. We will measure the total duration of the WHILE loop execution.

SET NOCOUNT ON

DECLARE @StartDate DATE
DECLARE @EndDate DATE
DECLARE @ST DATETIME 

DROP TABLE IF EXISTS [#Calendar]

CREATE TABLE [#Calendar] ( [CalendarDate] [DATE] NOT NULL PRIMARY KEY )

SET @StartDate = '1500-01-01'
SET @EndDate = '2100-12-31'

SET @ST = GETDATE()

   WHILE @StartDate <= @EndDate
   BEGIN
		
	INSERT INTO [#Calendar] VALUES (@StartDate)

	SET @StartDate = DATEADD(DAY, 1, @StartDate)

   END

PRINT DATEDIFF(ms, @ST, GETDATE())

SELECT * FROM [#Calendar] ORDER BY 1
GO

There are totally more than 200k rows for the 6 hundred years range inserted into the calendar table. The execution time is around 2.900 ms on my test machine with really small differences for multiple executions. Not bad, right?:)

But, can it be better? Let’s try. Instead of firing more than 200k atomic inserts, we can try to hit the line in one step using the Tally table horsepower.

SET NOCOUNT ON

DECLARE @StartDate DATE
DECLARE @EndDate DATE
DECLARE @ST DATETIME 

DROP TABLE IF EXISTS [#Calendar]

CREATE TABLE [#Calendar] ( [CalendarDate] [DATE] NOT NULL PRIMARY KEY )

SET @StartDate = '1500-01-01'
SET @EndDate = '2100-12-31'

SET @ST = GETDATE()

	;WITH Tally (n) AS
	(
		SELECT 
			ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
		FROM (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) a (n)
		   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) b (n)
		   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) c (n)
		   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) d (n)
		   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) e (n)
		   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) f (n)
	)
	INSERT INTO [#Calendar]
	   ( [CalendarDate] )
	   SELECT DATEADD(DAY, n-1, @StartDate) 
	   FROM Tally
	   WHERE DATEADD(DAY, n-1, @StartDate) <=  @EndDate
           --WHERE n <= DateDiff(Day, @StartDate, @EndDate) + 1
	   ORDER BY 1

PRINT DATEDIFF(ms, @ST, GETDATE())

SELECT * FROM [#Calendar] ORDER BY 1
GO

The same amount of rows was inserted into the calendar table. But instead of 3 seconds, it took about 360 ms now! Amazing.

There are two (or even more) possible WHERE clauses to limit the final number of rows we would like to get because the Tally table needs to be generated most of the time bigger than the final result set. In your case, there are 1.000.000 rows ready by the Tally table (the CROSS JOINs count * VALUEs count) but we need only 219.511 rows to be used for the required dates range. This is why we are using the WHERE condition to limit it.

It’s interesting to compare these two conditions via performance and their execution plans.

WHERE DATEADD(DAY, n-1, @StartDate) <= @EndDate => duration 360 ms

And the second one:

WHERE n <= DateDiff(Day, @StartDate, @EndDate) + 1 => duration 550 ms

This is quite an interesting difference in execution plans and performance. Looks like it depends on how data are finally sorted for the clustered index insert: if in Sort operator before or in Clustered Index Insert operator itself. If we will remove PRIMARY KEY constraint from the #Calendar table definition, both execution plans will align to be the same (except parallelism used or not in favor of the first WHERE condition). Btw, removing the clustered key will speed it up from about 360 ms to 90 ms. This is a great gain but the price is we can’t be sure all dates in the #Calendar table are unique and we will need to index the column soon or later to improve its usage in other queries.

The Tally table size

Our Tally table has a total size of 1.000.000 available numbers as mentioned above. Does it somehow affect the performance in this scenario? Let’s test it. We will remove some unnecessary (0) to limit available numbers to 300k only because we know this will be enough for our requested data range.

SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) a (n)
   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) b (n)
   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) c (n)
   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) d (n)
   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) e (n)
   CROSS JOIN (VALUES(0),(0),(0)) f (n)

With every (0) removed performance gets better by about 5-10%, in our case from about 360 ms to 220 ms. This is matching to linear scaling (one (0) is 100k rows removed). So it’s really important to size the Tally table as much as possible to what is needed.

We can optimize it further and remove this dependency if the Tally table will be prepared in advance, like in this sample:

DROP TABLE IF EXISTS [#Tally]

CREATE TABLE [#Tally] ( [n] [INT] NOT NULL PRIMARY KEY )

INSERT INTO [#Tally]
	( [n] )
SELECT 	ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) n
FROM (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) a (n)
   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) b (n)
   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) c (n)
   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) d (n)
   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) e (n)
   CROSS JOIN (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) f (n)
ORDER BY n
GO

DECLARE @StartDate DATE
DECLARE @EndDate DATE
DECLARE @ST DATETIME 

DROP TABLE IF EXISTS [#Calendar]

CREATE TABLE [#Calendar] ( [CalendarDate] [DATE] NOT NULL PRIMARY KEY )

SET @StartDate = '1500-01-01'
SET @EndDate = '2100-12-31'

SET @ST = GETDATE()

	INSERT INTO [#Calendar]
	   ( [CalendarDate] )
	   SELECT DATEADD(DAY, n-1, @StartDate) 
	   FROM #Tally
	   WHERE n <= DATEDIFF(day, @StartDate, @EndDate) + 1

PRINT DATEDIFF(ms, @ST, GETDATE())

SELECT * FROM [#Calendar] ORDER BY 1
GO

We have inserted 1.000.000 rows into the #Tally temporary table and indexed it using the PRIMARY KEY which means that clustered index was created. We have also modified the WHERE condition to limit the total number of n values used from the Tally table. The measured duration is now 80 ms with this execution plan:

The main reason why we should persist the Tally table and reuse it is not only because of the performance but the fact, that it nearly doesn’t matter how many rows we have in it. The set is ordered and Index Seek (or Scan) operator will need the same IO operations to stop at the desired number of rows required by the WHERE condition. If we will modify the above case and create #Tally table with 100 billion rows the duration and IOs will be the same (there will be a little bit different memory grants or other estimates).

Proceduru voláme podle následující šablony:

sp_get_query_template
   [ @querytext = ] N'query_text'
   , @templatetext OUTPUT 
   , @parameters OUTPUT

• @query text – dotaz, pro který chceme vygenerovat šablonu. Musí být uzavřen do jednoduchých uvozovek a označen jako unicode (N”).
• @templatetext – vrací text parametrizovaného dotaz
• @parameters – vrací seznam parametrů s datovými typy

Jak to vše funguje v praxi si ukážeme v tomto jednoduchém příkladu:

DECLARE @TemplateText NVARCHAR(MAX)
DECLARE @Parameters NVARCHAR(MAX)
 
EXEC sp_get_query_template
 N'SELECT *
 FROM [dbo].[TestTable]
 WHERE Id IN (5, 6) OR 
 Date BETWEEN GetDATE() AND ''2010-01-01'' OR
 Date = DATEADD(day, 1, GETDATE()) OR
 Date = GETDATE()',
 @templatetext OUTPUT,
 @parameters OUTPUT;

SELECT @TemplateText AS TemplateText;
SELECT @Parameters AS Parameters
GO

Bohužel i zde narazíme na drobná omezení, stačí se podívat na vygenerovanou šablonu v Management Studiu:

select * 
from [dbo] . [TestTable] 
where Id in ( @0 , @1 ) or 
	  Date between GetDATE ( ) and @2 or 
	  Date = DATEADD ( day , @3 , GETDATE ( ) ) or 
	  Date = GETDATE ( )

Vidíme, že v textu se vyskytují mezery mezi znaky, což představuje problém pro dynamické sql a bez dalšího formátování se neobejdeme. Pozornost je třeba věnovat i datovým typům parametrů, protože procedura sice správně pozná INT datové typy, ale pokud bude sloupec [Date] v tabulce dbo.TestTable datového typu DATE nebo DATETIME, dostaneme stejně parametr @2 jako varchar(8000) řetězec.

Ukážeme si jak na to s několika základními sloupci pro základní analýzu. Nebude zkoumat exekuční plány ani další detaily, zajímá nás opravdu jen to, jak si dotaz vede.

Základní kód vypadá takto:

SET NOCOUNT ON 

DECLARE @StartTime DATETIME 
DECLARE @CPU INT 
DECLARE @TotalElapsedTime INT 
DECLARE @QueryMemmory INT 
DECLARE @Reads INT 
DECLARE @Writes INT 
DECLARE @LogicalReads INT 
DECLARE @RowCount INT 
DECLARE @LastWaitType NVARCHAR(60) 
SELECT  @StartTime = start_time, @CPU = cpu_time, @TotalElapsedTime = total_elapsed_time, 
        @QueryMemmory = granted_query_memory, @Reads = reads, @Writes = writes, 
        @LogicalReads = logical_reads , @LastWaitType = last_wait_type, @RowCount = row_count 
FROM sys.dm_exec_requests 
WHERE session_id = @@SPID

-- QUERY TO TEST-- 

SELECT COUNT(*) NumOfCols FROM sys.columns 

--/QUERY -- 

SELECT CONVERT(NVARCHAR(20), @StartTime, 114) StartTime, 
       cpu_time - @CPU CPU, total_elapsed_time - @TotalElapsedTime TotalElapsedTime, 
       @QueryMemmory QueryMemmory, reads - @Reads Reads, 
       writes - @Writes Writes, logical_reads - @LogicalReads LogicalReads, 
       last_wait_type LastWaitType, row_count - @RowCount RowCnt 
FROM sys.dm_exec_requests 
WHERE session_id = @@SPID
GO

Vše je opravdu velmi jednoduché:

1. Nejprve si před vykonáním samotného dotazu uložíme do proměnných stav klíčových sloupců s dynamického systémovou pohledu sys.dm_exec_requests. Pomocí podmínky WHERE session_id = @@SPID zajistíme, že si uložíme hodnoty pouze pro naše aktivní připojení.
2. Vykonáme dotaz, který sledujeme.
3. Znovu si načteme ze sys.dm_exec_requests hodnoty sloupců tak, jak vypadají po vykonání dotazu a odečteme od nich hodnoty před spuštěním dotazu uložené v proměnných.

Které sloupce ze systémového pohledu si přidáme, případně zda využijeme i další systémové pohledy a získáme komplexní přehled, je již jen na nás.

Let’s demonstrate it.

We will prepare a table with sample values first. The table has [String] columns with Slovak_CI_AS collation.

-- create sample table
CREATE TABLE [dbo].[SampleTable]
(
    [Id] INT IDENTITY(1,1) PRIMARY KEY,
    [String] VARCHAR(200) COLLATE Slovak_CI_AS NULL
)
GO

-- populate test data
INSERT [dbo].[SampleTable]
    SELECT TOP 2000
        [o1].[name] + LEFT(CAST(NEWID() AS VARCHAR(36)), 6)
    FROM [sys].[objects] [o1]
        CROSS JOIN [sys].[objects] [o2]
GO

-- create simple index on search argument column
CREATE NONCLUSTERED INDEX [IX_String] ON [dbo].[SampleTable] ( [String] )
GO

We can run simple query and check its execution plan now:

SELECT *
FROM [dbo].[SampleTable]
WHERE [String] LIKE 'sysrow%'
GO

It has returned about 4 rows from a total of 2 thousand rows and Index Seek operator was selected by the optimizer.

Let’s modify the query and use COLLATE statement to convert it Czech_CI_AS collation first. This can be useful if we need to search for some language-specific letters like ř, š, or č.

-- execute query 2 and check execution plan
SELECT *
FROM dbo.SampleTable
WHERE String LIKE 'sysrow%' COLLATE Czech_CI_AS
GO

Index Seek operator was replaced by Index Scan operator which is much less effective for this particular query. You can see that it takes 75% from the total batch, 3x more than the one with Index Seek.

In the latest versions of SQL Server, there is an improvement in query plans explorer which will warn us about such a situation. There is and warning sign displayed for SELECT operator:

If we will move the mouse over it more detailed explanation pops up:

The warning is the same as for standard type conversion using CAST() or CONVERT() functions. When COLLATE is used, then SQL Server converts the data in columns to different collations internally.  That means that COLLATE should be avoided in WHERE clause and if this isn’t possible then its use should be rethought twice and performance impact considered.

Let’s see our example. We will create table [dbo].[SampleTable] with [Date] column and populate it with some sample data. Then we will create an index over the [Date] column which one we will expect to be used later by sample query.

-- Create sample table
CREATE TABLE [dbo].[SampleTable]
(
    [Id] INT IDENTITY(1,1) PRIMARY KEY,
    [Date] DATETIME
)
GO

-- Populate table with sample data
INSERT [dbo].[SampleTable]
    SELECT TOP 2000 DATEADD(dd, ROW_NUMBER() OVER (ORDER BY [o1].[object_Id], [o2].[object_Id]), 
                              dateadd(d, 0, datediff(d, 0, GETDATE())))
    FROM [sys].[objects] [o1]
        CROSS JOIN [sys].[objects] [o2]
GO

-- Create index on [Date] column
CREATE NONCLUSTERED INDEX [IX_Date] ON [dbo].[SampleTable] 
(
    [Date] ASC
)
GO

We will execute the following query to get all data for the specified year and check the execution plan:

SELECT * FROM [dbo].[SampleTable] WHERE YEAR([Date]) = '2011'

Index Scan was used to get requested data. This is not exactly what we would like to see because we have created an index and based od data selectivity we know that only a small subset of rows from the table should be returned. It is caused by the fact that we have used YEAR() function over the [Date] column which prevents the use of index seek because the YEAR() value needs to be calculated for every row first and then filtered further.

How to modify the query to replace Index Scan with Index Seek? It’s easy. Just think a little bit in dates and years:

SELECT * FROM dbo.SampleTable WHERE Date >= '2011-01-01' AND Date <= '2011-12-31'

We are getting exactly the same result set but this time Index Seek plan operator was selected by the query optimizer because YEAR() function was removed and our query is now simple seek for a range of values.

If we will execute both queries in a single batch, we can compare the performance gain we have achieved:

CREATE TABLE dbo.SampleTable 
(
    Id INT IDENTITY(1,1) PRIMARY KEY
)
GO

INSERT dbo.SampleTable
    DEFAULT VALUES
GO 256

Execute following queries and compare results and execution plans. The only one difference between statements is in the numer of rows to be requested by TOP operator (higlighted line).

Query 1:

SELECT 
    TOP 175
    (SELECT Id FROM dbo.SampleTable WHERE Id = CAST(CAST(NEWID() AS VARBINARY) AS TINYINT))
FROM dbo.SampleTable
GO

Query 2:

SELECT 
    TOP 176
    (SELECT Id FROM dbo.SampleTable WHERE Id = CAST(CAST(NEWID() AS VARBINARY) AS TINYINT))
FROM dbo.SampleTable
GO

This small change in the query (in fact requesting one more row) caused new execution plan to be generated. This is common situation in the SQL Server where the optimizer is cost-based. But what is for sure not expected and predictable is that a change in execution plan means a different result set. Our sample query returns after the execution plan change the same value for all rows instead of the random value as before.

Why that happened? The difference between execution plans can explain that: There is one new operator in the second plan: Table Spool. This operator is used by the query optimizer to persist temporal set of values to the tempdb for later use and it is blocking operator by nature. This process is used whenever the optimizer knows that the density of the column is high and the intermediate result is very complex to calculate. If this is the case the optimizer makes the computation once and stores the result in the temporary space so it can search it later.

My assumption is that when the SQL Server is fetching rows from and Clustered Index Seek into Table Spool operator, it’s changing the processing mode of an index seek from a row-by-row to batch mode internally that the full set of rows received by seeking the index can be delivered to Table Spool operator. The NEWID() function is then executed only once.

The difference between the number of executions for the Clustered Index Seek can be viewed on the operator properties dialog:

Query 1: 175 executions                                                Query 2: 1 execution

One question still remains: where the boundary value 176 is coming from? I’m not sure for now. It can be an internal optimizer threshold but this is hardly documented.

Further reading:

• Operator of the Week – Spools, Eager Spool
• Create a plan guide to cache (lazy spool) CTE result