Should I use Query Hint Fast number_rows / FASTFIRSTROW?

Will Shaver picture Will Shaver · Aug 20, 2009 · Viewed 10.1k times · Source

I was reading over the documentation for query hints: http://msdn.microsoft.com/en-us/library/ms181714(SQL.90).aspx

And noticed this: FAST number_rows Specifies that the query is optimized for fast retrieval of the first number_rows. This is a nonnegative integer. After the first number_rows are returned, the query continues execution and produces its full result set.

So when I'm doing a query like:

Select Name from Students where ID = 444

Should I bother with a hint like this? Assuming SQL Server 2005, when should I?

-- edit --

Also should one bother when limiting results:

Select top 10 * from Students OPTION (FAST 10)

Answer

Remus Rusanu picture Remus Rusanu · Aug 20, 2009

The FAST hint only makes sense on complex queries where there are multiple alternatives the optimizer could choose from. For a simple query like your example it doesn't help with anything, the query optimizer will immediately determine that there is a trivial plan (seek in ID index, lookup Name if not covering) to satisfy the query and go for it. Even if no index exists on ID, the plan is still trivial (probably clustered scan).

To give an example where FAST would be useful consider a join between A and B, with an ORDER BY constraint. Say evaluating the join B first and nested loops A honors the ORDER BY constraint, so will produce fast results (no SORT necessary), but is more costly because of cardinality (B has many records that match the WHERE, while A has few). On the other hand evaluating B first and nested loop A would produce a query that does less IO hence is faster overall, but the result would have to be sorted first and SORT can only start after the join is evaluated, so the first result will come very late. The optimizer would normally pick the second plan because is more efficient overall. The FAST hint would cause the optimizer to pick the first plan, because it produces results faster.