Question

I have a query of the following shape :

A
UNION ALL
B
UNION ALL
C
UNION ALL
D

And would like to parallelize it by calling A, B, C and D in parallel and then, union them in .Net. Those 4 queries all read data in the same pool of tables.

The first step I tried is to execute A in one Tab of SSMS and B in a second tab. A, and B last about 1 minute each, so I have the time to launch A, then go to tab B and launch it.

But when I look at CPU usage, it stalls at 13% (I'm on a 8 core CPU @ Windows), which corresponds to 100% of one core.

My questions : - do the "lock" mechanisms allow two queries on a given set of tables to run in parallel ? - if parallelism is possible, would I notice it by trying to run A and B in parallel in two SSMS tabs or is my test flawed ? - how would it be possible to improve the performance of that UNION ALL series eventually ?

Was it helpful?

Solution

You don't force parallelism at all. The engine decides it based on the query cost

See how to run a parallel query on sql server 2008?

In this case, you could open 4 connections to the database and run 4 querys and append the results. You'd use .net parallel processing to then join the result sets.

However, it will almost always be more efficient and simpler to UNION in the database.

Reading from the same pool of tables does not promote or prevent parallelism: shared locks are issued which don't block other readers. And the data will be cached so less IO is used.

If each UNION clause is taking too long then you have other problems such as poor indexes, old/no statistics, too little RAM, badly structured queries, tempdb issues... and many other possibilities

tl;dr

Fix the queries. Don't work around them.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top