July 20, 2010 at 1:47 am
Yes, the clustered index on TransactionID and Date.
I did try Chris' suggestion with the calendar table, it did make a huge difference. Anyway I can optimise it further looking at the execution plan??
July 20, 2010 at 2:24 am
LadyG (7/20/2010)
Yes, the clustered index on TransactionID and Date.I did try Chris' suggestion with the calendar table, it did make a huge difference. Anyway I can optimise it further looking at the execution plan??
Did you try changing your WHERE clause as per this post?
Did you try taking out the derived table? You need to ensure that removing this doesn't change the row count of the output.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
July 20, 2010 at 6:55 am
The query appears to be doing table scans on the tables TaxRules and Interface_CorrectionMethods. Ideally you would want to create some clustered indexes on these tables, do you have someone you can speak to internally about choosing the best candidates for the index?
Remember you should keep your clustered indexes as narrow as possible as they will also be included in your nonclustered indexes.
From looking at the plan once you have created you clustered indexes you may wish to create some nonclustered indexes to cover the fields you require in the query - obviously without knowing all the details about the table such as number of attributes and rows it would be difficult to recommend this from the outset.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply