I did some research online, and people are saying that the Parameter Sniffing could be the cause.  I tried to avoid it according to this post, but it didn’t make much difference as far as how long it takes for the Stored Procedure to complete.

After trying many different things, I finally found out the problem.  The Stored Procedure was dynamically created from user-defined query using SQL Server Management Object within our .NET web application.  We also allow users to define parameters (such as @Param1) in their Queries.  Since we don’t know the maximum length of the string parameter, we used varchar(MAX) for all string type parameters.  That’s the cause of this problem.  Once I changed the varchar(MAX) to varchar(200), the Stored Procedure started running much faster and the Execution Plan looks very similar to the simple Query now.  Problem solved.

Just for curiosity, I compared some other scenarios.  I found out that varchar(MAX) doesn’t always make a huge difference in performance.  The Stored Procedure I had problem with had a target table in a remote database (Linked Server) and the version of the remote SQL Server is 2000 where varchar(MAX) is not supported.  I am surprised that I didn’t get any exception when I run the query.  I am not sure what SQL Server does in the back end to make this unsupported data type to work, but apparently it slows down the query execution.