Comments on: Covering Index because it’s Covering up the truth?

By: Rob Farley

Rob Farley — Wed, 25 May 2011 16:35:11 +0000

Hi Amit,
Not quite. There is nowhere that tells us how many rows are being satisfied by the Seek Predicate and then need to be checked by the Residual.
But for the mostpart, I agree with you wholeheartedly.
Thanks for the comment!

By: Amit Banerjee

Amit Banerjee — Wed, 25 May 2011 16:20:31 +0000

The important point here is that consider the amount of rows being fetched and the number of executes involved in evaluating the join/filter condition in the plans. This is one of the reason I am still a fan of the text execution plan format. It lets me look at the operator, residuals, rows and executes along with the estimates. However, I am old school and people might differ with me on the use of text vs XML plans.
Just because it’s a SEEK doesn’t mean that you have the best plan! That is an urban-legend. 🙂

By: Rob Farley

Rob Farley — Wed, 25 May 2011 13:19:11 +0000

No problem, Robert. I figure there are scenarios where an Index Seek is in place, and people just assume it’s ideal, because people just love Seeks and hate Scans.

By: Robert L Davis

Robert L Davis — Wed, 25 May 2011 04:03:16 +0000

Excellent point Rob. Having a 2nd inequality value in the index doesn’t improve the usage. If anything, it will make the index a little bit bigger.
Anywho, I definitely agree with what you are saying here. I just got distracted by the fact that the covered index shouldn’t have been used in the first place.

By: Rob Farley

Rob Farley — Wed, 25 May 2011 02:24:39 +0000

Indeed Paul. A filtered index is definitely better, and if it’s covering as well, then great. A filtered index whose predicates match the query’s predicates doesn’t even need to check what’s there, it just grabs all the rows. It’s a thing of beauty, with no Residualicity.

By: Paul White

Paul White — Wed, 25 May 2011 02:18:34 +0000

Hi Rob,
Another important consideration people overlook with seeks is how it knows when to stop…
Just thought I’d chip that in ;c)
Paul

By: Rob Farley

Rob Farley — Wed, 25 May 2011 02:10:17 +0000

Of course, Robert, the ideal index for this query is the filtered index that I put at the end of the original post (http://sqlblog.com/blogs/rob_farley/archive/2011/05/19/covering-schmuvvering-when-a-covering-index-is-actually-rubbish.aspx), which causes an Index Scan that doesn't check the predicates at all.

By: Rob Farley

Rob Farley — Wed, 25 May 2011 02:00:23 +0000

Hi Robert,
Thanks for your comment.
I agree that a better index could be used. But my point is that a Covering Index Seek hides a lot of the truth if you don’t know to look at the Residual Predicate.
But tell me – why have you put ReorderPoint in as your third key? Can you explain why you consider this is better than having it in the Included list?
Rob

By: Robert L Davis

Robert L Davis — Wed, 25 May 2011 00:58:20 +0000

Reading this for the first time today, and I agree with the sentiment, but disagree with the demo.
The "Covering index" created for the sample is not a true covering index. Columns that should be in the key of the index are in the Includes list.
I’m assuming that this was contrived on purpose to demonstrate how a covering index seek may not be any better than a clustered scan. Let’s skip the whole fill factor aspect of it for now. This was admittedly contrived to force the seek of the covering index to require more logical reads (16) than the clustered index scan (15). Setting fill factor to the default value (100) reduces the logical page reads to 7.
However, even more telling is that simply creating the correctcovering index reduces the page reads to 2.
Using your example, I created the 2 following indexes:
CREATE INDEX rf_ix_Covering ON Production.Product(DaysToManufacture)
INCLUDE (Name, ProductNumber, Size, ReorderPoint, Color);
CREATE INDEX rf_ix_TrueCovering ON Production.Product(Color, DaysToManufacture, ReorderPoint)
INCLUDE (Name, ProductNumber, Size) ;
Then I ran the following forms of the query forcing it to use your covering index, the clustered index, and allowing it to pick its own index (it uses the covering index I created). I also used the recompile option and enabled Statistics IO and actual execution plan settings:
SELECT Name, ProductNumber
FROM Production.Product with(index(rf_ix_Covering))
WHERE DaysToManufacture < 4
AND ReorderPoint < 100
AND Color = ‘Red’
Option(recompile)
SELECT Name, ProductNumber
FROM Production.Product with(index(1))
WHERE DaysToManufacture < 4
AND ReorderPoint < 100
AND Color = ‘Red’
Option(recompile)
SELECT Name, ProductNumber
FROM Production.Product
WHERE DaysToManufacture < 4
AND ReorderPoint < 100
AND Color = ‘Red’
Option(recompile)
Statistics IO output (with row counts removed and LOB counts truncated) was:
Table ‘Product’. Scan count 1, logical reads 7, physical reads 0, read-ahead reads 0…
Table ‘Product’. Scan count 1, logical reads 15, physical reads 0, read-ahead reads 0…
Table ‘Product’. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0…
And the actual execution plans showed that the cost of the three queries when executed as a single batch are respectively 29%, 56%, and 15% of the total cost of the batch. This clearly demonstrates that the "bad covering index" is almost 50% the cost of the clustered index scan, and twice the cost of using the appropriate covering index.

By: Rob Farley

Rob Farley — Wed, 25 May 2011 00:23:30 +0000

I really hope everyone notices your wink there, Alex. 🙂