Comments on: Why is a Full Table Scan Selected – Will the Execution Plan Provide a Clue?

By: Log Buffer #275, A Carnival of the Vanities for DBAs | The Pythian Blog

Log Buffer #275, A Carnival of the Vanities for DBAs | The Pythian Blog — Fri, 22 Jun 2012 08:01:27 +0000

[...] is a Full Table Scan Selected – Will the Execution Plan Provide a Clue? Charles Hooper [...]

By: Charles Hooper

Charles Hooper — Wed, 20 Jun 2012 18:50:06 +0000

Tony,

Thanks for the comment. I added a small amount of additional information at the bottom of this blog article a couple of hours after you posted your comment.

Good point that the Starts column is 0, and identifying just what that means for the execution of the SQL statement. I am not sure yet about the Cost column – is it a bug, or an indended result?

Jonathan’s comments in the OTN thread might appear a bit harsh at first glance, yet those comments are spot on.

By: Tony Sleight

Tony Sleight — Wed, 20 Jun 2012 16:37:14 +0000

Charles,
This is a really great breakdown of a problem.

I have never seen the instance of the filter predicate (NULL IS NOT NULL) before. But, given this information it is hardly surprising the cost of a FTS (252) was ignored as the filter would always be FALSE. That was shown later in your analysis with the starts=0, the FTS was not executed, hence cost being a token value of 1 which I guess is the CPU cost.