I see a lot of searches from people apparently trying to find out what having a Constant Scan in their execution plan means. I can understand why. Here’s the definition from the Books Online:
The Constant Scan operator introduces one or more constant rows into a query. A Compute Scalar operator is often used to add columns to a row produced by a Constant Scan operator.
OK. Very precise and yet, unless you know what the sentence means, reading it can be pretty confusing. The key is to see what Compute Scalar means:
The Compute Scalar operator evaluates an expression to produce a computed scalar value. This may then be returned to the user, referenced elsewhere in the query, or both. An example of both is in a filter predicate or join predicate.
What this usually means is, when you have something like GETDATE() in your query, you’ll see a Compute Scalar. What does that have to do with Constant Scan? You’ll see situations where the query has to create a row to hold it’s data before it can access data from tables. The following example is taken from Dissecting SQL Server Execution Plans:
’1313 Mockingbird Lane’
In this example, the execution plan generated starts off with a Constant Scan where the engine creates a row that it begins to populate in order to generate the rest of the data for the insert. You’ll see Constant Scans created in other situations for the same purpose. I’ve seen them alot when querying against XML or creating XML.
Another instance of Constant Scans is when you have partitioned tables. As this explanation from Microsoft points out, the Constant Scans in these situations represent the partitions.
It’s usually not a big deal or a major performance bottleneck. Spend time worrying about other operators.