Configuration of Cost threshold for Parallelism

Question

Hi all, 
I want to adjust the 'Cost Threshold for Parallelism' on the SQL server running  OLTP databases.
MSDN says that this is an estimate query duration - in seconds.
Is this estimate available in a DMV? I want to look at my server's query workload & assess which queries I want to be considered for parallel processing and which ones I don't.
Some potential candidates include:
dm_exec_query_stats.max_elapsed_time / dm_exec_query_stats.execution_count
I don't want to use this as this actual - where the setting is an estimate (on some arbitrary server).
I thought it might be the Estimated Subtree Cost in the query plan? Though I've read this has nothing to do with an estimated number of seconds.
Any assistance greatly appreciated.
Cheers, Clay

Answer 1

Thanks for the replies SQL24 and Ashwin - 
I am looking at a server which is struggling to keep up with a substantial increase in volumes.
My top 3 waits are:
- CXPACKET @ 55%
- LCK_M_IX @ 25%
- SOS_SCHEDULER_YIELD @9% (25% signal waits)
The production server has only 2 CPUs - the current MAXDOP and Cost Threshold for Parallelism are the default, 0 and 5. 
Though 2 CPUs is a tiny amount of CPU - I'm hesitant to request more until I can prove CPU is struggling (my 
In regards to "issues relating to parallelism" - my guess (I'm not a DBA) is
that too many queries are being parallelised - I'm basing this guess on the high level of waits on CXPACKET, the fact that it is primarily managing small transactions (+ plus some manifesting/grouping of those transactions each afternoon)  & the
fact that I currently only have 2 CPUs! 
To my original question - MSDN states "The
cost refers to an estimated elapsed time in seconds required to run the serial plan on a specific hardware configuration"
http://technet.microsoft.com/en-us/library/ms188603(v=sql.105).aspx
It is the 'specific hardware configuration' part of this description that renders all of the actual times (be it a max or average) that I can obtain from
dm_exec_query_stats worthless.... for this purpose.
My guess (again) was that it could be compared to the query plans estimated subtree cost - but before I attempted extraction of this info from query plans - I wanted to confirm.
Thanks again.