Setup Cost of Threshold for Parallelism : 5 Max Degree of Parallelism : 4

Question

0

Editorial Team

Asked: May 20, 20262026-05-20T09:30:01+00:00 2026-05-20T09:30:01+00:00

Setup Cost of Threshold for Parallelism : 5 Max Degree of Parallelism : 4

0

Setup

Cost of Threshold for Parallelism : 5
Max Degree of Parallelism : 4
Number of Processors : 8
SQL Server 2008 10.0.2.2757
I have a query with many joins, many records.
The design is a star. ( Central table with fks to the reference tables )
The central table is partitioned on the relevant date column.
The partition schema is split by days
The data is very well split across the partition schema – as judged by comparing the sizes of the files in the filegroups assigned to the partition schema
Queries involved have the predicate set over the partitioned column. such as ( cs.dte >= @min_date and cs.dte < @max_date )
The values of the date parameters are a day apart @ midnight so, 2010-02-01, 2010-02-02
The estimated query plan shows no parallelism

a) This question is in regards to Sql Server 2008 Database Engine. When a query in the OLTP engine is running, I would like to see / have the sort of insight one gets when profiling an SSAS Query using Progress End event – where one sees something like “Done reading PartititionXYZ”.

b) if the estimated query plan or the actual query plan shows no parallel processing does that mean that all partitions will be / were checked / read? * What I was trying to say here was – just b/c I don’t see parallelism in a query plan, that doesn’t guarantee the query isn’t hitting multiple partitions – right? Or – is there a solid relationship between parallelism and # partitions accessed?

c) suggestions? Is there more information that I need to provide?

d) how can I tell if a query is processing in parallel w/o looking @ the actual query plan? * I’m really only interested in this if it is helpful in pinning down what partitions are being used.

Added Nov 10

Try this:

Create querys that should hit 1, 3, and all your partitions
Open an SSMS query window, and run SET SHOWPLAN_XML ON
Run each query one by one in that window
Each run will kick out a chunk of XML
Compare these XML results (I use a text diff tool, “CompareIt”, but any similar tool would do)

You should see that the execution plans are significantly different. In my “3” and “All” querys, there’s a chunk of text tagged as “ConstantScan” that has an entry for (respectively) 3 and All partitions in the table, and that section is not present for the “1 partition” query. I use this to infer that yes indeed, SQL doing what it says it will do, to wit: only read as much of the table as it believes it needs to in order to resovle the query.