I have seen plenty examples where they have set it to 1

Is 1 an even number  :-)

this is a 2 x Xeon E5430 (quad core 2.66GHz)

24GB memory,

Windows Server 2008, SQL 2008 Feb 08 CTP 32-bit

CPU and time to run the 22 TPC-H queries in milli-sec

for the second run, ie, all data in memory, some tempdb activity

CPU Dur

DOP 1 506,519 521,837

DOP 2 429,826 233,002

DOP 3 447,162 164,048

DOP 4 443,498 126,309

DOP 5 461,700 106,154

DOP 6 474,525 93,883

DOP 7 487,316 81,246

DOP 8 482,945 71,141

on big systems, I have always tested 1, 2, 4, 8, 16, 32 & 64 CPUs because I don't have time to do the off numbers before the big box is put into production, or the customer is tired of paying my hourly rate for such infor

same for SQL 2005 sp2

CPU Dur

DOP 1 470,562 488,147

DOP 2 397,489 214,126

DOP 3 418,737 154,524

DOP 4 404,916 122,397

DOP 5 417,864 103,803

DOP 6 429,469 92,684

DOP 7 438,160 84,302

DOP 8 442,155 73,631

same for SQL 2000 sp4 + hf 2187

CPU Dur

DOP 1 511,948 544,520

DOP 2 547,157 285,508

DOP 3 570,946 220,855

DOP 4 612,977 191,639

DOP 5 618,670 184,473

DOP 6 661,789 178,591

DOP 7 688,495 170,236

DOP 8 727,634 166,110

interpreting parallel execution performance characteristics is not a simple matter, and it is very easy for a less experienced person to draw completely wrong conclusions

This is the first of a four-part series: Introduction to Query Parallelism (this post) Flipping the Bit

Here's something I'm running into when trying a query using MAXDOP, on SQL Server 2005 SP2: I get different results if I use "OPTION (MAXDOP 1)" and "OPTION (maxdop 1)", and that's on a case-insensitive server.

Also, it appears that BCP ignores it, since I'll have all processors hit 100%, even when using "OPTION (MAXDOP 1)" within a query (using queryout)