2008 we've been able to use CONVERT(DATE) and still utilize an index on that column, which is quite powerful. I did this three times for each method, and they all ran in the range of 34-38 seconds. So strictly speaking, there are very negligible differences in these methods when performing the operations in memory: A More Elaborate Performance Test I also wanted to compare these methods with different data types ( DATETIME , SMALLDATETIME , and DATETIME2 ), against both a clustered index and a heap, and with and without data compression. So first I created a simple database. Through experimentation I determined that the optimal size to handle 120 million rows and all of the log activity that might incur (and to prevent auto-grow events from interfering with the testing) was a 20GB data file and a 3GB log: Here we see that the convert to date and the open-ended range using an index are the best performers. However, against a heap, the convert to date actually takes some time, making the open-ended range the optimal choice ( click to enlarge ): And here are the second set of queries (again, repeating for each table type): Focusing on the results for tables with a clustered index, it is clear that the convert to date was a very close performer to just selecting the raw data ( click to enlarge ): (For this set of queries, the heap showed very similar results -- practically indistinguishable.) Conclusion In case you wanted