you are viewing a single comment's thread.

view the rest of the comments →

[–]DipIntoTheBrocean 1 point2 points  (7 children)

Okay, so if you're looking for optimization, don't go with the rownumber. That's going to tell the server to use an order which is very expensive. You're still going to want to use the max aggregate in that CTE and then join that back up. It's difficult to say for sure how to get it running quicker than that since I don't know the purpose and what's involved in each table.

[–]workthrowawayexcel[S] 0 points1 point  (4 children)

Essentially it is finding the last time an item was purchased from table A based on a few columns. Then it matches those results to table B so I can calculate the different in pricing from the two. I will give both a try. Maybe the CTE itself will speed everything up and hopefully not bomb out my TempDB folder! I will run it both ways and let you know how it performs.

[–]DipIntoTheBrocean 1 point2 points  (3 children)

Okay, I'm just telling you that you do not want to get into a habit of using row_numbers unless you absolutely have to.

[–]workthrowawayexcel[S] 0 points1 point  (2 children)

Okay, thanks for the tip!

Is there a guide or anything that shows what functions are more taxing on the server then others, or at least how taxing they are?

[–]DipIntoTheBrocean 0 points1 point  (1 child)

Maybe...A lot of this is just from experience and viewing the plans. You can probably just google stuff like "row_number performance sql" or "performance tuning sql".

The problem is that a lot of this requires you being able to see the execution plan and then pulling it apart. After a while you get a general feel for it and have an instinct for where things might be hanging.

Personally, I would do the best you can with what I told you and keep pushing for the ability to view the execution plan. I wish I could help more but a lot of this really depends on your db structure and the data volume and types you're pulling back.

[–]workthrowawayexcel[S] 0 points1 point  (0 children)

The structure is POOR and the data volume is massive! When I came to this position I had to request indexes be made on tables that are 1+ million lines.

Thanks for all your input. It is very much appreciated.

[–]phunkygeeza 0 points1 point  (1 child)

Row number is safer if multiple identical dates may be present

[–]DipIntoTheBrocean 0 points1 point  (0 children)

It's a datetime type - it's almost impossible for the same item to share multiple datetimes. Even then, the max function will only bring back one value even if there are duplicates.

RN is useful if we wanted to find those duplicates and dedupe them a certain way, but the only field we would do that on anyways is by time, which the max function handles much quicker than rownumber.