I think the issue lies with the fact that the plan generated for the query is a “Trivial Plan”. This can be checked by clicking on the Select icon on the Actual Execution plan and looking at the “Optimisation Level” value in the properties window.

In this case the statistics do get marked for update by the background auto-update stats process but aren’t actually updated since the Trivial Plan present in the cache is never recompiled irrespective of the number of times it is used. This is true even if we encapsulate the select into a stored procedure.

The statistics update on the city column is triggered by operations like (though not limited to)
- Explicit Procedure/Plan recompilation
- DBCC FREEPROCCACHE
- OPTION RECOMPILE as per John’s suggestion above
- New query compiled which makes use of the statistics created on this column as per Arunraj’s suggestion above

More information can be found under the heading “Skipping the Recompilation Step” on this link:

http://technet.microsoft.com/en-us/library/cc293623.aspx

Hope this makes sense!

Regards
Chirag

i.e., run this before round 2:
————————————————————–
– Clear execution plan cache before next test
DBCC FREEPROCCACHE WITH NO_INFOMSGS;
————————————————————–

Nice puzzle!

Kevin

Although the column statistics are invalidated by the time the second select statement is executed, the query is not compiled/recompiled but instead the existing query plan is reused.

It is the “next” compiled query against the column statistics that will see that they are out of date and will then in turn instantiate the action of updating statistics.

You can see this in action by forcing the second statement to recompile.

SELECT FirstName, LastName, City
FROM ExecTable
WHERE City = ‘New York’ option(RECOMPILE)
GO

SELECT FirstName, LastName, City
FROM ExecTable
WHERE City = ‘New York’

and allowing the optimizer to reuse the existing plan ,which is considered as most optimal plan .

If we crate an Index

CREATE CLUSTERED INDEX IDX ON ExecTable(id)

Insert 1000 rows frist then

SELECT FirstName, LastName, City
FROM ExecTable
WHERE City = ‘New York’

– this statement compiles it first time to keep track of subsequent executions

and

insert next 700 rows (as per the algorithm its 500 + 20% rows changed)

Then check your statistics using
DBCC SHOW_STATISTICS

we can see statistics updated.

INSERT INTO ExecTable (ID,FirstName,LastName,City)
SELECT TOP 1000 ROW_NUMBER() OVER (ORDER BY a.name) RowID,
‘Bob’,'smith’,'New York’
FROM sys.all_objects a
CROSS JOIN sys.all_objects b
GO

CREATE CLUSTERED INDEX IDX ON ExecTable(id)

GO

SELECT FirstName, LastName, City
FROM ExecTable
WHERE city = ‘New York’

sp_helpstats N’ExecTable’, ‘ALL’
DBCC SHOW_STATISTICS(ExecTable, ‘statistics’)

GO

INSERT INTO ExecTable (ID,FirstName,LastName,City)
SELECT TOP 700 ROW_NUMBER() OVER (ORDER BY a.name) RowID,
‘Bob’,'smith’,'New York’
FROM sys.all_objects a
CROSS JOIN sys.all_objects b

DBCC SHOW_STATISTICS(ExecTable, ‘statistics’)

Go

But, when there is no Index:

Ex: when there are no Indexes

1) First insert 1000 rows

2)Compile statemnt
3) insert 700 rows
4) insert 850 rows (as per the algorithm)

Then Check your Statistics those will be updated.

INSERT INTO ExecTable (ID,FirstName,LastName,City)
SELECT TOP 1000 ROW_NUMBER() OVER (ORDER BY a.name) RowID,
‘Bob’,'smith’,'New York’
FROM sys.all_objects a
CROSS JOIN sys.all_objects b

GO

SELECT FirstName, LastName, City
FROM ExecTable
WHERE city = ‘New York’

sp_helpstats N’ExecTable’, ‘ALL’
DBCC SHOW_STATISTICS(ExecTable, ‘statistics’)

GO

INSERT INTO ExecTable (ID,FirstName,LastName,City)
SELECT TOP 700 ROW_NUMBER() OVER (ORDER BY a.name) RowID,
‘Bob’,'smith’,'New York’
FROM sys.all_objects a
CROSS JOIN sys.all_objects b

Go

INSERT INTO ExecTable (ID,FirstName,LastName,City)
SELECT TOP 850 ROW_NUMBER() OVER (ORDER BY a.name) RowID,
‘Bob’,'smith’,'New York’
FROM sys.all_objects a
CROSS JOIN sys.all_objects b

sp_helpstats N’ExecTable’, ‘ALL’

DBCC SHOW_STATISTICS(ExecTable, ‘statistics’)

AUTO UPDATE STATS and AUTO CREATE STATS will be enabled by default when creating new database.

Regards
Arun Raj.C

http://msdn.microsoft.com/en-us/library/ms173416(v=SQL.100).aspx

Statistics is initially created while retrieving the data from table using the RowSample as 1000 records which are initially inserted, when we insert the Next 10000 records and retrieving the data with same Filter criteria, Query optimizer will reuse the Same Statistics, so its not triggering the engine to update Statistics

If you check the Statistics Updated time after inserting 10000 records, it will be same as before.

If we change the Filter criteria like this

SELECT FirstName, LastName, City
FROM ExecTable
WHERE FirstName=’Bob’ and City=’New York’

It will trigger the Statistics Update process and create a new statistics based on FirstName and also update the Statistics based on City

Warm Regards
Arunraj Chandrasekaran