Hello Gert-Jan Strik,
in my example I’ve reduced the query to bare minimum, so that the problem is visible only in bad estimates, not in the cpu time or logical reads. The real query is a bit more complex and joins a couple of other dimensions and a bridge table to the result of the DimDatum/FactTable join, and then there is of course a huge performance impact, because SQL Server expects 1 row from the DimDatum/FactTable join but receives much more instead.
Example query for the script you posted:
SELECT f.DatumID,f.SomeFacts,dd.LastVersion, someBridgeTable.Risikofaktor2ID
--INTO #t
FROM dbo.FactTable f
INNER JOIN dbo.DimDatum AS dd
ON f.DatumID = dd.DatumID
AND dd.LastVersion = 1
INNER JOIN dbo.FactTable someBridgeTable
ON f.DatumID = someBridgeTable.DatumID
AND f.Risikofaktor1ID = someBridgeTable.Risikofaktor1ID
WHERE
dd.DatumID >= 2013011500 AND dd.DatumID < 2013011600
OPTION(RECOMPILE)
No comments:
Post a Comment