SQL is creating a parallel query, and this is independent of the size of the table. Without seeing the query and schema details etc. it's impossible to analyze much more than that.
Run the select in Management Studio and look at the execution plan (actual not estimated). If you post it to the forum some one will give you some pointers.
There are a number of issues with MAXDOP = 0 (or not = 1) on OLTP servers. One of them is the problem you are getting here. A quick fix is to either add a query hint of MAXDOP = 1 to the select, or set MAXDOP = 1 via sp_configure. This is a very contentious issue between dba's but here is a really good article:
If you only have one problem query I'd add the query hint. If you have lots of problem queries I'd consider setting MAXDOP = 1. On an OLTP server, where you expect almost all queries to be well optimized and indexes to be well designed for performance your queries should run serialised anyway, as you would expect all queries to run under the cost threshold of 5. Setting MAXDOP = 1 prevents the odd poorly performing query from affecting the other queries.
This is not a decision to be made lightly and you need to consider all the options and TEST, TEST, TEST.
Nothing in life is ever so complicated that with a little work it can't be made more complicated.