May 28, 2015 at 6:10 pm
GilaMonster (5/28/2015)
WhiteLotus (5/27/2015)
I just tested the query by eliminating DISTINCT ..the result is :
(45108 row(s) affected)
Table 'project_text'. Scan count 1, logical reads 2017, physical reads 0, read-ahead reads 0, lob logical reads 62693, lob physical reads 0, lob read-ahead reads 0.
The same result like before
And the comparative output of STATISTICS time for the queries with and without DISTINCT? Removing it's not going to change the logical reads, the same amount of data still has to be read from the table.
btw, why are you tuning a query that runs under 1 second and does ~2000 reads?
Hmm this is a good question, I tune this query cause it is in the top 5 expensive queries for a period of 2 weeks ( I monitor this using tool which display the graphic) . Now I think it will better to tune other queries which has much longer time ..
Many thanks for your kind help 🙂 ..now i am going for other queries
May 28, 2015 at 6:13 pm
Grant Fritchey (5/28/2015)
First question, did the execution time change with the removal of DISTINCT with the original indexing scheme?Next question, did either of those indexes get used? Did you check the execution plan to see if they were picked up by the optimizer or did it stick with the original index. If it didn't choose those, we might want to try an index hint here. But, this part, it's desperation to squeeze a little bit of performance out. It won't make a major difference. The real problem is the volume of data we're attempting to move. There's no way, within a query or index, to simply make that "fast." Moving that much data is largely dependent on hardware.
It didn't change at all mate ...but that's ok I think I better move on other queries which has longer time ..
Thanks for your kind help 🙂
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply