CPU intensive query#3

please attach the .sqlplan file

http://msdn.microsoft.com/en-us/library/ms190646.aspx

Well, same request as in your other posts: The entire batch and the actual execution plan, please.

here you go.
ExecutionPlan1.sqlplan

#ResolveIsFuture.[DestinationID] as [RF].[DestinationID]=[iXTrade_Main].[dbo].[tbRateAnalysis].[rDestinationID] as [R].[rDestinationID]

I am guessing that the #ResolveIsFuture.[DestinationID] is not indexed but that the "left semi join" between those 2 tables would be improved by indexing that field.

"I am guessing that the #ResolveIsFuture.[DestinationID] is not indexed "


because that one is the output list is #ResolveIsFuture.[DestinationID]  and this means profiler is looking for an index of that column ?

but that one is a table in tempdB, right? so just index that tempdb table ?

"Which version of SQL Server you have?"

SQL server 2008 R2 SP2 with CU4

"tbRateAnalysis.DestinationID should be indexed. And also #ResolveIsFuture.DestinationID."

I think it should be tbRateAnalysis.RateAnalysisID and #ResolveIsFuture.DestinationID, right?

it only has index :

CREATE NONCLUSTERED INDEX [IX_tbRateReAnalysis] ON [dbo].[tbRateReAnalysis]
(
	[ReAnalyzeID] ASC,
	[SourceID] ASC,
	[sDestinationID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, 

ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
GO


CREATE NONCLUSTERED INDEX [IX_tbRateReAnalysis_1] ON [dbo].[tbRateReAnalysis]
(
	[ReAnalyzeID] ASC,
	[SourceID] ASC,
	[rDestinationID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
GO

Select allOpen in new window

but #ResolveIsFuture is a tempDb table, riht we can simply just go ahead to add an index for it?

Not tbRateAnalysis.RateAnalysisID because you don't use that column in the query.
Also your tbRateReAnalysis.rDestinationID is part of an composed index so SQL Server engine might not use it. That's why you sould create an index only for that field.

When you run the query in SSMS in the query plan view you don't see a line on the top of the diagram advising the creation of an index?

"Also your tbRateReAnalysis.rDestinationID is part of an composed index so SQL Server engine might not use it. That's why you sould create an index only for that field."

I think as long as composed index cover that column, it should be choosen too, right? that why we can sometimes combine index to save space while the index still useful ?

the predicates section show which column an index is being look for ?
 
I think the output  list show me what index SQL is looking for.

"
 When you run the query in SSMS in the query plan view you don't see a line on the top of the diagram advising the creation of an index? "

 
where  ? what did you see?

By the query plan isn't using any index, that's why you have a table scan. You should have at least an index scan and you don't have it, so isn't using indexes at all.

And don't create composed indexes for save space. Isn't the idea for these type of indexes. Indexes are for increase performance and not for save space. You create a composed index if you have a long running query that use all those columns and in the same order.

You should see any index creation advice below the query cost and before the diagram. If you don't have it it's because SQL Server engine doesn't think that the query will need it.

It's only the temp table that doesn't have this index.....

#ResolveIsFuture.[DestinationID]

there is an index already being used for [iXTrade_Main].[dbo].[tbRateAnalysis].[rDestinationID] ...

 <RelOp NodeId="3" PhysicalOp="Nested Loops" LogicalOp="Left Semi Join" ...

<ScalarOperator ScalarString="#ResolveIsFuture.[DestinationID] as [RF].[DestinationID]=[iXTrade_Main].[dbo].[tbRateAnalysis].[rDestinationID] as [R].[rDestinationID]">

Select allOpen in new window

"You should see any index creation advice below the query cost and before the diagram. If you don't have it it's because SQL Server engine doesn't think that the query will need it. "

I just think you read my plan and you see something.

but one thing, will that place shows all missing indexs we need to create? or just one only ?

"You should have at least an index scan and you don't have it, so isn't using indexes at all.
"

index scan also means performance problem, right? what should be done for that? rebuilt index and update statistics?

"You create a composed index if you have a long running query that use all those columns and in the same order."

so that's why we will have a lot of index for a table anyway !

but in the same order here means ?

"there is an index seek"

it should not be a prblem, right?

"it is the temp table causing the table scan through a left join "

so the only problem is
#ResolveIsFuture.[DestinationID] do not have an index? which case a table scan ?

Thanks PortletPaul. Didn't see that before.
Then marrowyung just need to create the index in #ResolveIsFuture.

If there is more missing indexes, please post them here.

Cheers

tks. clear enought !