Quantcast
Viewing all articles
Browse latest Browse all 15889

Cardinality estimates on a parallel join are wrong

Hello everybody,

I'm having a problem with pretty simple query where the cardinality estimates seems to be off and usual methods that I knew for this kind of problem don't help.

The query:
SELECT COUNT(*) FROM
     dbo.FaktMVaR mvar
         INNER JOIN dbo.FaktSensitivitaet AS sen
                 ON mvar.DatumID = sen.DatumID
                    AND mvar.Risikofaktor1ID = sen.Risikofaktor1ID
                    AND mvar.Risikofaktor2ID = sen.Risikofaktor2ID         
         INNER JOIN dbo.DimDatum AS dd
                 ON mvar.DatumID = dd.DatumID
                    AND dd.LastVersion = 1
WHERE dd.DatumID >= 2012122700 and dd.DatumID < 2012122800 

Image may be NSFW.
Clik here to view.

As obviously seen in the execution plan, the join result contains actually 217Mio rows. The query optimizer expects for join of FaktSensitivitaet with FaktMVaR only 30Mio rows. Other estimates are fine.
I've already tried the following:
1. Created multi-column statistics WITH FULLSCAN for FaktSensitivitaet and FaktMVaR on 3 join columns (DatumID, Risikofaktor1ID, Risikofaktor2ID).
2. Instead of (1) created filtered indices with exactly the WHERE conditions on FaktSensitivitaet and FaktMVaR incliding (DatumID, Risikofaktor1ID, Risikofaktor2ID)
3. Updated statistics behind the clustered indices of both Fakt* tables WITH FULLSCAN.

I can provide DBCC SHOW_STATISTICS results for (1) and (2), and usually multicolumn statistics solved similar join issues.

FaktSensitivitaet (limited to date condition in where) has 723K rows, FaktMVaR - 548K rows. The 217Mio are produced through M2M relations between these tables (the result is expected and correct).

After all I've tried playing with MAXDOP query hints. They do provide positive results (MAXDOP 1 inserts a stream aggregate before huge join, MAXDOP 8 inserts a hash match aggregate), and the queries actually returned instantly (compared to 13 seconds before). Unfortunately this doesn't help in my real query which still runs slow and with wrong estimates.

I've looked at http://sqlblog.com/blogs/paul_white/archive/2011/12/06/sql-server-optimizer-bug-with-join-and-group-by.aspx
but I'm not sure whether this is my case.

I'm using SQL Server 2008 R2 SP1. Any help or hints whether the parallel execution is my problem and in what CU/Service Pack this issue could be solved is very appreciated.


Viewing all articles
Browse latest Browse all 15889

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>