In my DOP Feedback post last month, I shared something very frustrating. I had all the documented prerequisites for DOP Feedback in place. Query Store in READ_WRITE mode, DOP_FEEDBACK enabled at the database scope, Compatibility Level 160, MAXDOP set to 14, and a repeatable workload generating real parallelism waits -- but the DOP feedback never fired. No dop_feedback_eligible_query event. No entries in sys.query_store_plan_feedback. Nothing.
I said I'd follow with a sequel when I found a workload that does become eligible, and then I'd compare it against the one that did not. Well. This is that sequel, but I still don't have it. Today is honestly my fourth full-day of testing without triggering any DOP Feedback.
Rather than sh*t canning the whole thing, I thought I'd put out here what I've learned about that doesn't trigger DOP Feedback.
What I Did Right, and What Wasn't The Problem
To clarify right up front, it wasn't my configuration. ALL documented prereqs were satisfied.
The first time around, I believed the problem was my workload. I built a single query, verified it was going parallel at DOP 14, and hammered it repeatedly on an otherwise idle server. THAT was my error, and that is why the feedback loop never engaged.
The DOP Feedback feature isn't meant to flag a single query on an idle server. It is looking for concurrency issues, thread synchronization overhead, and resource contention within a repeating, multi-user workload.
It's looking for queries that burn through server worker threads and act as resource hogs when the database is legitimately under pressure.
Or, as Erik Darling says, "for parallelism, it's less about individual query performance, and more about overall server/workload performance."
First Attempt: My Code
I had created a stored procedure that forced a parallel scan with an ORDER BY on a non-indexed column. The query went parallel with DOP 14 and showed measurable waits:
| Wait Type | Increase During Test |
|---|---|
| CXPACKET | +27,678 ms |
| CXCONSUMER | +23,424 ms |
| CXSYNC_PORT | +1,130 ms |
| CXSYNC_CONSUMER | +62 ms |
Thought I had something usable, so I ran the workload using ostress with multiple connections:
ostress completes and then I checked sys.query_store_plan_feedback:
SELECT
qspf.plan_id,
qspf.feature_desc,
qspf.state_desc,
qspf.feedback_data,
qspf.last_updated_time
FROM sys.query_store_plan_feedback qspf
WHERE qspf.plan_id IN (553, 558, 527, 525)
ORDER BY qspf.last_updated_time DESC;
Look at that. CE Feedback evaluated the query but made no recommendation. Memory Grant Feedback evaluated it and decided the feedback was warranted. But DOP Feedback (feature_id = 3) is completely absent. The query was parallel, it was repeating, and other IQP features were engaging -- but DOP Feedback never even looked my way.
Even with heavy, concurrent activity, I still can't trigger the DOP Feedback. I've read the docs again and again, still not finding the fine print that I am missing. So I decided to change my approach.
Second Attempt: The Official Microsoft Demo Query
Maybe my query was the problem. I really don't like copying someone else's code, but after four full days of this, I ran out of reasons not to. I went to Microsoft's demo that's documented to work, and I created the stored procedure from the BobSQL repository:
CREATE OR ALTER PROCEDURE [Warehouse].[GetStockItemsbySupplier] @SupplierID int AS BEGIN SELECT StockItemID, SupplierID, StockItemName, TaxRate, LeadTimeDays FROM Warehouse.StockItems s WHERE SupplierID = @SupplierID ORDER BY StockItemName; END; GO
I populated the data using a modified version of their populatedata.sql script only because the original version ate up too much of my disk -- but I checked when complete, verified the skew and confirmed the DOP at 14. Then I ran the workload exactly as the demo specifies, using workload_index_scan_users.cmd from the command prompt.
And I got the same result:
SELECT
qspf.plan_id,
qspf.feature_desc,
qspf.state_desc,
qspf.last_updated_time
FROM sys.query_store_plan_feedback qspf
ORDER BY qspf.last_updated_time DESC;
Again, no DOP Feedback. Memory Grant Feedback was working. The query was in Query Store and was parallel. But DOP Feedback never evaluated it.
Digging Deeper: The BobSQL Demo Steps
Still not ready to scrap it, I went through the BobSQL demo step-by-step (again). The readme lists 15 steps. Here's the full accounting:
| Step | BobSQL Demo | What I Actually Did |
|---|---|---|
| 1 | configmaxdop.sql (MAXDOP = 0) | ✓ MAXDOP = 0 |
| 2 | Copy WWI backup | ✓ Did |
| 3 | Edit restorewwi.sql paths | ✓ Did |
| 4 | Execute restorewwi.sql | ✓ Did |
| 5 | populatedata.sql (full run) | ✗ Ran modified version - 3.5M rows, not full ~6.5GB |
| 6 | Rebuild indexes | ✓ Did |
| 7 | dopfeedback.sql | ✓ Did |
| 8 | proc.sql | ✓ Did |
| 9 | dopxe.sql | ✓ Did |
| 10 | workload_index_scan_users.cmd | ✓ Ran exactly as documented |
| 11 | Monitor XE session | ✓ Checked ring buffer |
| 12 | dop_query_stats.sql | ✓ Did |
| 13 | Top Resource Consuming Queries report | ✓ Did |
| 14 | check_query_feedback.sql | ✓ Did |
| 15 | Top Resource Consuming Queries report (Avg) | ✓ Did |
The BobSQL demo is documented to work in Microsoft's published test environment. I reproduced every step except the full data load, which simply exceeded the free disk space on my laptop. Everything else matched the published configuration and workload, yet DOP Feedback still never engaged in my environment.
What I Learned About DOP Feedback's Eligibility
Here's what I now understand based on my testing:
1. The documented prerequisites are necessary but not sufficient.
You can have everything Microsoft says you need, and still never trigger the feature. My testing proved that with both my own query and the official demo query.
2. Other IQP features engaging doesn't mean DOP Feedback will.
Memory Grant Feedback worked consistently on both queries. CE Feedback evaluated one of them. But DOP Feedback never engaged. Presumably, the eligibility criteria are independent and more restrictive.
3. The exact eligibility criteria remain undocumented.
Microsoft describes how the feature works but doesn't publish the internal thresholds that determine when a query crosses the eligibility line. This is consistent with other Intelligent Query Processing features like Memory Grant Feedback, where the internal tuning logic is also opaque.
4. The 'proven' demo requires a specific environment.
The BobSQL demo works in their documented test environment (8 CPUs, 24GB RAM, dedicated VM, fast NVMe storage). My environment is a laptop with 14 CPUs, 16GB RAM (12GB allocated to SQL Server), and NVMe storage. Still robust, but clearly different enough that DOP Feedback was never engaged. Replicating the demo in a different environment may not produce the same results.
The Bottom Line
DOP Feedback has been proven elsewhere, but it's more selective than I expected, and I could not get it to talk to me. Four full rounds of testing. All the documented prerequisites were in place, and I tested with my own query and the official Microsoft demo query. The other IQP features were engaging, but DOP Feedback never evaluated either query.
Not quite the sequel I had planned on, but all of this testing has changed my understanding of DOP Feedback considerably. I no longer think of it as a feature that reacts to 'big parallel queries'. Whatever Microsoft's internal eligibility model is, it's considerably more selective than the public documentation suggests. I still haven't crossed that line -- but I certainly eliminated several assumptions that I started this one with.
If you've successfully triggered DOP Feedback in your environment, I'd love to hear about it. Leave a comment and share what worked for you.
More to Read
sqlfingers — DOP Feedback Part 1
Lee Brownhill: Learning SQL Server 2025 - DOP Feedback
SQLYARD: MAXDOP and DOP Feedback in SQL Server 2022 - The Complete Guide
Microsoft BobSQL Demo: DOP Feedback
Pinal Dave: SQL Server 2022 - DOP Feedback