Impact of partition scan on large and small data I have a table SampleTable which has a clustered index on Date column, and is also partitioned on Date column. However the Date column is of type DateTime. 

While querying from this table i.e. 

Select * from SampleTable where Convert(Date,Date) &gt;= Convert(Date,GETDATE())-1


... I convert Date column to Date datatype. This makes my search predicate seek on all partitions. 

However, changing the query to:

Select * from SampleTable where Date &gt;= Convert(Date,GETDATE())-1


... causes the search predicated to seek only on partitions which qualify. 

I wanted to understand the impact of the seek operations. Will the impact be linear or exponential when my data/date range increases?

The index is always being used.
Think of it as different queries. How much it cost to navigate a B-Tree to find zero rows? That is what happens for those "extra partitions". Those that don't contain any data for your range and which are skipped with your second query alternative. If you don't have too many partitions, then this extra cost will be very low. But as number of partitions increase, so will the overhead (especially relative overhead if the selectivity for the range is high).