Unique filtered index and surprising estimation
up vote
3
down vote
favorite
When I view the estimated execution plan for this query...
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod
... the Estimated Number of Rows property for [table1]
shows 10. Why is this? In the schema (copied below) I have a unique index AKF_tabela1_Kod
. Shouldn't this unique index force the row estimation to be 1?
Estimated Execution Plan
Create Database, Tables and Index
-- create database
USE [master]
GO
DROP DATABASE IF EXISTS my_test;
CREATE DATABASE my_test;
GO
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
ALTER AUTHORIZATION ON DATABASE ::my_test TO sa;
USE my_test
GO
-- create dbo.tabela1
CREATE TABLE dbo.[tabela1]
(
[Id] int NOT NULL identity(1,1),
[kol1] varchar(20) NOT NULL,
[Kod] int NULL,
CONSTRAINT [PK_tabela1] PRIMARY KEY NONCLUSTERED([id] ASC) WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON),
CONSTRAINT [BK_tabela1] UNIQUE CLUSTERED([Kol1] ASC) WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON),
);
GO
-- create Index
CREATE UNIQUE NONCLUSTERED INDEX [AKF_tabela1_Kod]
ON dbo.[tabela1]([Kod] ASC)
INCLUDE ([id],[kol1])
WHERE ([Kod] IS NOT NULL)
WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, MAXDOP = 0);
GO
-- create dbo.tabela2
IF OBJECT_ID('dbo.tabela2') IS NULL
CREATE TABLE tabela2 (Kod int NOT NULL)
GO
Insert Data into Table
-- create data in tabela1
declare @i int=1
while @i<=100
begin
INSERT tabela1 (kol1, kod)
values (@i, cast(@i+100 as varchar))
set @i += 1;
end;
GO
UPDATE STATISTICS tabela1 WITH FULLSCAN;
Here the Execution plan
sql-server execution-plan
New contributor
|
show 2 more comments
up vote
3
down vote
favorite
When I view the estimated execution plan for this query...
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod
... the Estimated Number of Rows property for [table1]
shows 10. Why is this? In the schema (copied below) I have a unique index AKF_tabela1_Kod
. Shouldn't this unique index force the row estimation to be 1?
Estimated Execution Plan
Create Database, Tables and Index
-- create database
USE [master]
GO
DROP DATABASE IF EXISTS my_test;
CREATE DATABASE my_test;
GO
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
ALTER AUTHORIZATION ON DATABASE ::my_test TO sa;
USE my_test
GO
-- create dbo.tabela1
CREATE TABLE dbo.[tabela1]
(
[Id] int NOT NULL identity(1,1),
[kol1] varchar(20) NOT NULL,
[Kod] int NULL,
CONSTRAINT [PK_tabela1] PRIMARY KEY NONCLUSTERED([id] ASC) WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON),
CONSTRAINT [BK_tabela1] UNIQUE CLUSTERED([Kol1] ASC) WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON),
);
GO
-- create Index
CREATE UNIQUE NONCLUSTERED INDEX [AKF_tabela1_Kod]
ON dbo.[tabela1]([Kod] ASC)
INCLUDE ([id],[kol1])
WHERE ([Kod] IS NOT NULL)
WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, MAXDOP = 0);
GO
-- create dbo.tabela2
IF OBJECT_ID('dbo.tabela2') IS NULL
CREATE TABLE tabela2 (Kod int NOT NULL)
GO
Insert Data into Table
-- create data in tabela1
declare @i int=1
while @i<=100
begin
INSERT tabela1 (kol1, kod)
values (@i, cast(@i+100 as varchar))
set @i += 1;
end;
GO
UPDATE STATISTICS tabela1 WITH FULLSCAN;
Here the Execution plan
sql-server execution-plan
New contributor
1
Why is there an exclamation mark in your Index Seek?
– McNets
5 hours ago
I've checked it on my server and on fiddle and the ENR = 1. The Plan
– McNets
5 hours ago
Because the automatic statistics creation option has been disabled on the database. If there is a dedicated index filtered (seek) on a column , why do I need the statistics not filtered on the entire column? Rhetorical is the question :). The question is, why SQL Server does not correctly estimate the number of rows based on a unique filtered index? Is this a paradox that uses a unique index and estimates a value greater than 1?
– coders
3 hours ago
It might be easier for people to answer if you share the execution plan.
– sp_BlitzErik
3 hours ago
Here you are :) : brentozar.com/pastetheplan/?id=r1oPgB6y4
– coders
3 hours ago
|
show 2 more comments
up vote
3
down vote
favorite
up vote
3
down vote
favorite
When I view the estimated execution plan for this query...
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod
... the Estimated Number of Rows property for [table1]
shows 10. Why is this? In the schema (copied below) I have a unique index AKF_tabela1_Kod
. Shouldn't this unique index force the row estimation to be 1?
Estimated Execution Plan
Create Database, Tables and Index
-- create database
USE [master]
GO
DROP DATABASE IF EXISTS my_test;
CREATE DATABASE my_test;
GO
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
ALTER AUTHORIZATION ON DATABASE ::my_test TO sa;
USE my_test
GO
-- create dbo.tabela1
CREATE TABLE dbo.[tabela1]
(
[Id] int NOT NULL identity(1,1),
[kol1] varchar(20) NOT NULL,
[Kod] int NULL,
CONSTRAINT [PK_tabela1] PRIMARY KEY NONCLUSTERED([id] ASC) WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON),
CONSTRAINT [BK_tabela1] UNIQUE CLUSTERED([Kol1] ASC) WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON),
);
GO
-- create Index
CREATE UNIQUE NONCLUSTERED INDEX [AKF_tabela1_Kod]
ON dbo.[tabela1]([Kod] ASC)
INCLUDE ([id],[kol1])
WHERE ([Kod] IS NOT NULL)
WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, MAXDOP = 0);
GO
-- create dbo.tabela2
IF OBJECT_ID('dbo.tabela2') IS NULL
CREATE TABLE tabela2 (Kod int NOT NULL)
GO
Insert Data into Table
-- create data in tabela1
declare @i int=1
while @i<=100
begin
INSERT tabela1 (kol1, kod)
values (@i, cast(@i+100 as varchar))
set @i += 1;
end;
GO
UPDATE STATISTICS tabela1 WITH FULLSCAN;
Here the Execution plan
sql-server execution-plan
New contributor
When I view the estimated execution plan for this query...
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod
... the Estimated Number of Rows property for [table1]
shows 10. Why is this? In the schema (copied below) I have a unique index AKF_tabela1_Kod
. Shouldn't this unique index force the row estimation to be 1?
Estimated Execution Plan
Create Database, Tables and Index
-- create database
USE [master]
GO
DROP DATABASE IF EXISTS my_test;
CREATE DATABASE my_test;
GO
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
ALTER AUTHORIZATION ON DATABASE ::my_test TO sa;
USE my_test
GO
-- create dbo.tabela1
CREATE TABLE dbo.[tabela1]
(
[Id] int NOT NULL identity(1,1),
[kol1] varchar(20) NOT NULL,
[Kod] int NULL,
CONSTRAINT [PK_tabela1] PRIMARY KEY NONCLUSTERED([id] ASC) WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON),
CONSTRAINT [BK_tabela1] UNIQUE CLUSTERED([Kol1] ASC) WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON),
);
GO
-- create Index
CREATE UNIQUE NONCLUSTERED INDEX [AKF_tabela1_Kod]
ON dbo.[tabela1]([Kod] ASC)
INCLUDE ([id],[kol1])
WHERE ([Kod] IS NOT NULL)
WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, MAXDOP = 0);
GO
-- create dbo.tabela2
IF OBJECT_ID('dbo.tabela2') IS NULL
CREATE TABLE tabela2 (Kod int NOT NULL)
GO
Insert Data into Table
-- create data in tabela1
declare @i int=1
while @i<=100
begin
INSERT tabela1 (kol1, kod)
values (@i, cast(@i+100 as varchar))
set @i += 1;
end;
GO
UPDATE STATISTICS tabela1 WITH FULLSCAN;
Here the Execution plan
sql-server execution-plan
sql-server execution-plan
New contributor
New contributor
edited 2 hours ago
McNets
14k41754
14k41754
New contributor
asked 6 hours ago
coders
161
161
New contributor
New contributor
1
Why is there an exclamation mark in your Index Seek?
– McNets
5 hours ago
I've checked it on my server and on fiddle and the ENR = 1. The Plan
– McNets
5 hours ago
Because the automatic statistics creation option has been disabled on the database. If there is a dedicated index filtered (seek) on a column , why do I need the statistics not filtered on the entire column? Rhetorical is the question :). The question is, why SQL Server does not correctly estimate the number of rows based on a unique filtered index? Is this a paradox that uses a unique index and estimates a value greater than 1?
– coders
3 hours ago
It might be easier for people to answer if you share the execution plan.
– sp_BlitzErik
3 hours ago
Here you are :) : brentozar.com/pastetheplan/?id=r1oPgB6y4
– coders
3 hours ago
|
show 2 more comments
1
Why is there an exclamation mark in your Index Seek?
– McNets
5 hours ago
I've checked it on my server and on fiddle and the ENR = 1. The Plan
– McNets
5 hours ago
Because the automatic statistics creation option has been disabled on the database. If there is a dedicated index filtered (seek) on a column , why do I need the statistics not filtered on the entire column? Rhetorical is the question :). The question is, why SQL Server does not correctly estimate the number of rows based on a unique filtered index? Is this a paradox that uses a unique index and estimates a value greater than 1?
– coders
3 hours ago
It might be easier for people to answer if you share the execution plan.
– sp_BlitzErik
3 hours ago
Here you are :) : brentozar.com/pastetheplan/?id=r1oPgB6y4
– coders
3 hours ago
1
1
Why is there an exclamation mark in your Index Seek?
– McNets
5 hours ago
Why is there an exclamation mark in your Index Seek?
– McNets
5 hours ago
I've checked it on my server and on fiddle and the ENR = 1. The Plan
– McNets
5 hours ago
I've checked it on my server and on fiddle and the ENR = 1. The Plan
– McNets
5 hours ago
Because the automatic statistics creation option has been disabled on the database. If there is a dedicated index filtered (seek) on a column , why do I need the statistics not filtered on the entire column? Rhetorical is the question :). The question is, why SQL Server does not correctly estimate the number of rows based on a unique filtered index? Is this a paradox that uses a unique index and estimates a value greater than 1?
– coders
3 hours ago
Because the automatic statistics creation option has been disabled on the database. If there is a dedicated index filtered (seek) on a column , why do I need the statistics not filtered on the entire column? Rhetorical is the question :). The question is, why SQL Server does not correctly estimate the number of rows based on a unique filtered index? Is this a paradox that uses a unique index and estimates a value greater than 1?
– coders
3 hours ago
It might be easier for people to answer if you share the execution plan.
– sp_BlitzErik
3 hours ago
It might be easier for people to answer if you share the execution plan.
– sp_BlitzErik
3 hours ago
Here you are :) : brentozar.com/pastetheplan/?id=r1oPgB6y4
– coders
3 hours ago
Here you are :) : brentozar.com/pastetheplan/?id=r1oPgB6y4
– coders
3 hours ago
|
show 2 more comments
1 Answer
1
active
oldest
votes
up vote
4
down vote
the Estimated Number of Rows property for [table1] shows 10. Why is
this? In the schema (copied below) I have a unique index
AKF_tabela1_Kod. Shouldn't this unique index force the row estimation
to be 1?
The statistics are created when creating the unique index, but as a result of the unique index being filtered, the statistics are also filtered.
(where kod is not null).
As a result, the query as it is cannot use these statistics.
Why?
The Index can be used, but the statistics are not a match for the query.
Even if you do a select on kod:
select kod from dbo.tabela1 t
where kod is not null option(recompile)
The statistics are still no match:
If you do a select of the id however:
select id from dbo.tabela1 t
where kod is not null option(recompile)
There is a match:
This seems to be buggy with auto create stats:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
This does not create stats for some reason, but is still able to do the correct estimation.
No new stats:
Re running this:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
Gives the same warning:
This seems to be an issue with auto create statistics being off, even though no stats are created.
I am not sure, but an estimate of 10 might be a 'default' value to use, like when using a table variable.
Workarounds:
1
If you create the next index, the result will be 1 estimated rows
CREATE UNIQUE NONCLUSTERED INDEX [AKF_tabela1_Kod2]
ON dbo.[tabela1]([Kod] ASC)
INCLUDE ([id])
WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, MAXDOP = 0);
GO
2
Another route you could take is creating your own statistics:
create statistics ST_Tablea1_Kod on dbo.tabela1(kod)
Retry the query (with a new execution plan):
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
3
Or ofcourse, enable auto create statistics and rerun the query:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
Update:
The below queries give a stat missing on the first execution, but not on the other two. A statistic was created by auto create stats.
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
Dropping the stats and retrying with a select:
drop statistics dbo.tabela1.[_WA_Sys_00000003_0EA330E9]
select kod from dbo.tabela1 t
where kod is not null option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
Does not generate stats, and gives the same missing index hints on the first and third execution:
I thought that this maybe was because of the optimization level being trivial. But this was not the case.
StatementOptmLevel="TRIVIAL"
Non trivial optimization level:
select kod from dbo.tabela1 t
where kod is not null
group by kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null group by kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null group by kod option(recompile)
Result:
Query #2 with automatic stat creation:
(I added 100 rows for a total of 200)
Query #3 , after putting automatic stat creation off again:
(180 estimated rows)
Did you refresh the statistics branch? (Right-click | Refresh) Just asking. I've had friends that were missing whole database, because they didn't refresh the branch in SSMS.
– hot2use
1 hour ago
I think (not very scientific i know) i did. But even if i didn't, after setting auto create stats off again, it should still give the result without the warning right? You might actually be correct, Im going to have to check again when i get home and correct any mistakes
– Randi Vertongen
1 hour ago
There where no stats created on the simple select. These plans are trivial however, which might be the explanation.
– Randi Vertongen
9 mins ago
@RandiVertongen you can add a silly subquery in a where clause to get full optimization (WHERE 1 = (SELECT 1)
). See here for more info.
– jadarnel27
5 mins ago
Thanks Jadarnel27, i added a group by to force the optimization, still the same issue found.
– Randi Vertongen
2 mins ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
the Estimated Number of Rows property for [table1] shows 10. Why is
this? In the schema (copied below) I have a unique index
AKF_tabela1_Kod. Shouldn't this unique index force the row estimation
to be 1?
The statistics are created when creating the unique index, but as a result of the unique index being filtered, the statistics are also filtered.
(where kod is not null).
As a result, the query as it is cannot use these statistics.
Why?
The Index can be used, but the statistics are not a match for the query.
Even if you do a select on kod:
select kod from dbo.tabela1 t
where kod is not null option(recompile)
The statistics are still no match:
If you do a select of the id however:
select id from dbo.tabela1 t
where kod is not null option(recompile)
There is a match:
This seems to be buggy with auto create stats:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
This does not create stats for some reason, but is still able to do the correct estimation.
No new stats:
Re running this:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
Gives the same warning:
This seems to be an issue with auto create statistics being off, even though no stats are created.
I am not sure, but an estimate of 10 might be a 'default' value to use, like when using a table variable.
Workarounds:
1
If you create the next index, the result will be 1 estimated rows
CREATE UNIQUE NONCLUSTERED INDEX [AKF_tabela1_Kod2]
ON dbo.[tabela1]([Kod] ASC)
INCLUDE ([id])
WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, MAXDOP = 0);
GO
2
Another route you could take is creating your own statistics:
create statistics ST_Tablea1_Kod on dbo.tabela1(kod)
Retry the query (with a new execution plan):
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
3
Or ofcourse, enable auto create statistics and rerun the query:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
Update:
The below queries give a stat missing on the first execution, but not on the other two. A statistic was created by auto create stats.
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
Dropping the stats and retrying with a select:
drop statistics dbo.tabela1.[_WA_Sys_00000003_0EA330E9]
select kod from dbo.tabela1 t
where kod is not null option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
Does not generate stats, and gives the same missing index hints on the first and third execution:
I thought that this maybe was because of the optimization level being trivial. But this was not the case.
StatementOptmLevel="TRIVIAL"
Non trivial optimization level:
select kod from dbo.tabela1 t
where kod is not null
group by kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null group by kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null group by kod option(recompile)
Result:
Query #2 with automatic stat creation:
(I added 100 rows for a total of 200)
Query #3 , after putting automatic stat creation off again:
(180 estimated rows)
Did you refresh the statistics branch? (Right-click | Refresh) Just asking. I've had friends that were missing whole database, because they didn't refresh the branch in SSMS.
– hot2use
1 hour ago
I think (not very scientific i know) i did. But even if i didn't, after setting auto create stats off again, it should still give the result without the warning right? You might actually be correct, Im going to have to check again when i get home and correct any mistakes
– Randi Vertongen
1 hour ago
There where no stats created on the simple select. These plans are trivial however, which might be the explanation.
– Randi Vertongen
9 mins ago
@RandiVertongen you can add a silly subquery in a where clause to get full optimization (WHERE 1 = (SELECT 1)
). See here for more info.
– jadarnel27
5 mins ago
Thanks Jadarnel27, i added a group by to force the optimization, still the same issue found.
– Randi Vertongen
2 mins ago
add a comment |
up vote
4
down vote
the Estimated Number of Rows property for [table1] shows 10. Why is
this? In the schema (copied below) I have a unique index
AKF_tabela1_Kod. Shouldn't this unique index force the row estimation
to be 1?
The statistics are created when creating the unique index, but as a result of the unique index being filtered, the statistics are also filtered.
(where kod is not null).
As a result, the query as it is cannot use these statistics.
Why?
The Index can be used, but the statistics are not a match for the query.
Even if you do a select on kod:
select kod from dbo.tabela1 t
where kod is not null option(recompile)
The statistics are still no match:
If you do a select of the id however:
select id from dbo.tabela1 t
where kod is not null option(recompile)
There is a match:
This seems to be buggy with auto create stats:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
This does not create stats for some reason, but is still able to do the correct estimation.
No new stats:
Re running this:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
Gives the same warning:
This seems to be an issue with auto create statistics being off, even though no stats are created.
I am not sure, but an estimate of 10 might be a 'default' value to use, like when using a table variable.
Workarounds:
1
If you create the next index, the result will be 1 estimated rows
CREATE UNIQUE NONCLUSTERED INDEX [AKF_tabela1_Kod2]
ON dbo.[tabela1]([Kod] ASC)
INCLUDE ([id])
WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, MAXDOP = 0);
GO
2
Another route you could take is creating your own statistics:
create statistics ST_Tablea1_Kod on dbo.tabela1(kod)
Retry the query (with a new execution plan):
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
3
Or ofcourse, enable auto create statistics and rerun the query:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
Update:
The below queries give a stat missing on the first execution, but not on the other two. A statistic was created by auto create stats.
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
Dropping the stats and retrying with a select:
drop statistics dbo.tabela1.[_WA_Sys_00000003_0EA330E9]
select kod from dbo.tabela1 t
where kod is not null option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
Does not generate stats, and gives the same missing index hints on the first and third execution:
I thought that this maybe was because of the optimization level being trivial. But this was not the case.
StatementOptmLevel="TRIVIAL"
Non trivial optimization level:
select kod from dbo.tabela1 t
where kod is not null
group by kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null group by kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null group by kod option(recompile)
Result:
Query #2 with automatic stat creation:
(I added 100 rows for a total of 200)
Query #3 , after putting automatic stat creation off again:
(180 estimated rows)
Did you refresh the statistics branch? (Right-click | Refresh) Just asking. I've had friends that were missing whole database, because they didn't refresh the branch in SSMS.
– hot2use
1 hour ago
I think (not very scientific i know) i did. But even if i didn't, after setting auto create stats off again, it should still give the result without the warning right? You might actually be correct, Im going to have to check again when i get home and correct any mistakes
– Randi Vertongen
1 hour ago
There where no stats created on the simple select. These plans are trivial however, which might be the explanation.
– Randi Vertongen
9 mins ago
@RandiVertongen you can add a silly subquery in a where clause to get full optimization (WHERE 1 = (SELECT 1)
). See here for more info.
– jadarnel27
5 mins ago
Thanks Jadarnel27, i added a group by to force the optimization, still the same issue found.
– Randi Vertongen
2 mins ago
add a comment |
up vote
4
down vote
up vote
4
down vote
the Estimated Number of Rows property for [table1] shows 10. Why is
this? In the schema (copied below) I have a unique index
AKF_tabela1_Kod. Shouldn't this unique index force the row estimation
to be 1?
The statistics are created when creating the unique index, but as a result of the unique index being filtered, the statistics are also filtered.
(where kod is not null).
As a result, the query as it is cannot use these statistics.
Why?
The Index can be used, but the statistics are not a match for the query.
Even if you do a select on kod:
select kod from dbo.tabela1 t
where kod is not null option(recompile)
The statistics are still no match:
If you do a select of the id however:
select id from dbo.tabela1 t
where kod is not null option(recompile)
There is a match:
This seems to be buggy with auto create stats:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
This does not create stats for some reason, but is still able to do the correct estimation.
No new stats:
Re running this:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
Gives the same warning:
This seems to be an issue with auto create statistics being off, even though no stats are created.
I am not sure, but an estimate of 10 might be a 'default' value to use, like when using a table variable.
Workarounds:
1
If you create the next index, the result will be 1 estimated rows
CREATE UNIQUE NONCLUSTERED INDEX [AKF_tabela1_Kod2]
ON dbo.[tabela1]([Kod] ASC)
INCLUDE ([id])
WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, MAXDOP = 0);
GO
2
Another route you could take is creating your own statistics:
create statistics ST_Tablea1_Kod on dbo.tabela1(kod)
Retry the query (with a new execution plan):
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
3
Or ofcourse, enable auto create statistics and rerun the query:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
Update:
The below queries give a stat missing on the first execution, but not on the other two. A statistic was created by auto create stats.
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
Dropping the stats and retrying with a select:
drop statistics dbo.tabela1.[_WA_Sys_00000003_0EA330E9]
select kod from dbo.tabela1 t
where kod is not null option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
Does not generate stats, and gives the same missing index hints on the first and third execution:
I thought that this maybe was because of the optimization level being trivial. But this was not the case.
StatementOptmLevel="TRIVIAL"
Non trivial optimization level:
select kod from dbo.tabela1 t
where kod is not null
group by kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null group by kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null group by kod option(recompile)
Result:
Query #2 with automatic stat creation:
(I added 100 rows for a total of 200)
Query #3 , after putting automatic stat creation off again:
(180 estimated rows)
the Estimated Number of Rows property for [table1] shows 10. Why is
this? In the schema (copied below) I have a unique index
AKF_tabela1_Kod. Shouldn't this unique index force the row estimation
to be 1?
The statistics are created when creating the unique index, but as a result of the unique index being filtered, the statistics are also filtered.
(where kod is not null).
As a result, the query as it is cannot use these statistics.
Why?
The Index can be used, but the statistics are not a match for the query.
Even if you do a select on kod:
select kod from dbo.tabela1 t
where kod is not null option(recompile)
The statistics are still no match:
If you do a select of the id however:
select id from dbo.tabela1 t
where kod is not null option(recompile)
There is a match:
This seems to be buggy with auto create stats:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
This does not create stats for some reason, but is still able to do the correct estimation.
No new stats:
Re running this:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
Gives the same warning:
This seems to be an issue with auto create statistics being off, even though no stats are created.
I am not sure, but an estimate of 10 might be a 'default' value to use, like when using a table variable.
Workarounds:
1
If you create the next index, the result will be 1 estimated rows
CREATE UNIQUE NONCLUSTERED INDEX [AKF_tabela1_Kod2]
ON dbo.[tabela1]([Kod] ASC)
INCLUDE ([id])
WITH (ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, MAXDOP = 0);
GO
2
Another route you could take is creating your own statistics:
create statistics ST_Tablea1_Kod on dbo.tabela1(kod)
Retry the query (with a new execution plan):
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
3
Or ofcourse, enable auto create statistics and rerun the query:
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
Update:
The below queries give a stat missing on the first execution, but not on the other two. A statistic was created by auto create stats.
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
SELECT *
FROM tabela2 x
LEFT JOIN dbo.tabela1 t with (nolock) on t.Kod = x.Kod option(recompile)
Dropping the stats and retrying with a select:
drop statistics dbo.tabela1.[_WA_Sys_00000003_0EA330E9]
select kod from dbo.tabela1 t
where kod is not null option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null option(recompile)
Does not generate stats, and gives the same missing index hints on the first and third execution:
I thought that this maybe was because of the optimization level being trivial. But this was not the case.
StatementOptmLevel="TRIVIAL"
Non trivial optimization level:
select kod from dbo.tabela1 t
where kod is not null
group by kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS ON;
select kod from dbo.tabela1 t
where kod is not null group by kod option(recompile)
ALTER DATABASE my_test SET AUTO_CREATE_STATISTICS OFF;
select kod from dbo.tabela1 t
where kod is not null group by kod option(recompile)
Result:
Query #2 with automatic stat creation:
(I added 100 rows for a total of 200)
Query #3 , after putting automatic stat creation off again:
(180 estimated rows)
edited 2 mins ago
answered 2 hours ago
Randi Vertongen
78011
78011
Did you refresh the statistics branch? (Right-click | Refresh) Just asking. I've had friends that were missing whole database, because they didn't refresh the branch in SSMS.
– hot2use
1 hour ago
I think (not very scientific i know) i did. But even if i didn't, after setting auto create stats off again, it should still give the result without the warning right? You might actually be correct, Im going to have to check again when i get home and correct any mistakes
– Randi Vertongen
1 hour ago
There where no stats created on the simple select. These plans are trivial however, which might be the explanation.
– Randi Vertongen
9 mins ago
@RandiVertongen you can add a silly subquery in a where clause to get full optimization (WHERE 1 = (SELECT 1)
). See here for more info.
– jadarnel27
5 mins ago
Thanks Jadarnel27, i added a group by to force the optimization, still the same issue found.
– Randi Vertongen
2 mins ago
add a comment |
Did you refresh the statistics branch? (Right-click | Refresh) Just asking. I've had friends that were missing whole database, because they didn't refresh the branch in SSMS.
– hot2use
1 hour ago
I think (not very scientific i know) i did. But even if i didn't, after setting auto create stats off again, it should still give the result without the warning right? You might actually be correct, Im going to have to check again when i get home and correct any mistakes
– Randi Vertongen
1 hour ago
There where no stats created on the simple select. These plans are trivial however, which might be the explanation.
– Randi Vertongen
9 mins ago
@RandiVertongen you can add a silly subquery in a where clause to get full optimization (WHERE 1 = (SELECT 1)
). See here for more info.
– jadarnel27
5 mins ago
Thanks Jadarnel27, i added a group by to force the optimization, still the same issue found.
– Randi Vertongen
2 mins ago
Did you refresh the statistics branch? (Right-click | Refresh) Just asking. I've had friends that were missing whole database, because they didn't refresh the branch in SSMS.
– hot2use
1 hour ago
Did you refresh the statistics branch? (Right-click | Refresh) Just asking. I've had friends that were missing whole database, because they didn't refresh the branch in SSMS.
– hot2use
1 hour ago
I think (not very scientific i know) i did. But even if i didn't, after setting auto create stats off again, it should still give the result without the warning right? You might actually be correct, Im going to have to check again when i get home and correct any mistakes
– Randi Vertongen
1 hour ago
I think (not very scientific i know) i did. But even if i didn't, after setting auto create stats off again, it should still give the result without the warning right? You might actually be correct, Im going to have to check again when i get home and correct any mistakes
– Randi Vertongen
1 hour ago
There where no stats created on the simple select. These plans are trivial however, which might be the explanation.
– Randi Vertongen
9 mins ago
There where no stats created on the simple select. These plans are trivial however, which might be the explanation.
– Randi Vertongen
9 mins ago
@RandiVertongen you can add a silly subquery in a where clause to get full optimization (
WHERE 1 = (SELECT 1)
). See here for more info.– jadarnel27
5 mins ago
@RandiVertongen you can add a silly subquery in a where clause to get full optimization (
WHERE 1 = (SELECT 1)
). See here for more info.– jadarnel27
5 mins ago
Thanks Jadarnel27, i added a group by to force the optimization, still the same issue found.
– Randi Vertongen
2 mins ago
Thanks Jadarnel27, i added a group by to force the optimization, still the same issue found.
– Randi Vertongen
2 mins ago
add a comment |
coders is a new contributor. Be nice, and check out our Code of Conduct.
coders is a new contributor. Be nice, and check out our Code of Conduct.
coders is a new contributor. Be nice, and check out our Code of Conduct.
coders is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f224640%2funique-filtered-index-and-surprising-estimation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Why is there an exclamation mark in your Index Seek?
– McNets
5 hours ago
I've checked it on my server and on fiddle and the ENR = 1. The Plan
– McNets
5 hours ago
Because the automatic statistics creation option has been disabled on the database. If there is a dedicated index filtered (seek) on a column , why do I need the statistics not filtered on the entire column? Rhetorical is the question :). The question is, why SQL Server does not correctly estimate the number of rows based on a unique filtered index? Is this a paradox that uses a unique index and estimates a value greater than 1?
– coders
3 hours ago
It might be easier for people to answer if you share the execution plan.
– sp_BlitzErik
3 hours ago
Here you are :) : brentozar.com/pastetheplan/?id=r1oPgB6y4
– coders
3 hours ago