Timeline for Why does my query take a long time to run, and why does changing the order of the joins make it quicker?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 12 at 1:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Aug 7 at 13:06 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Apr 6 at 1:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Dec 6, 2023 at 17:07 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Nov 4, 2023 at 5:39 | answer | added | Caleb Carl | timeline score: 0 | |
| Jan 27, 2023 at 15:00 | history | tweeted | twitter.com/StackDBAs/status/1618987200112197633 | ||
| Jan 27, 2023 at 14:48 | comment | added | Denis Rubashkin | You should update statistics on the server A. Some of used statistics were last updated in 2020 and have nonzero modification count. | |
| Jan 26, 2023 at 23:27 | comment | added | Martin Smith | In plan (a) the slowest bit is the repeated full scans and sorts of AssetValueHistory (that looks to be doing some sort of window function where the predicate on AssetId isn't pushed down to the table but it ends up ranking the entire table 1624 times and cumulatively reading 192,578,792 rows across those 1,624 executions. That subtree takes 2 mins 33 seconds | |
| Jan 26, 2023 at 22:57 | history | migrated | from stackoverflow.com (revisions) | ||
| Jan 26, 2023 at 22:47 | comment | added | sTTu | The links for pastetheplan are the preferred and recommended way of sharing an execution plan for this type of question | |
| Jan 26, 2023 at 22:15 | comment | added | Sean Lange | You seem to have a lot of views in these queries. What are those views doing? Do you have nested views? Have you updated statistics on your databases? There seems to be some large discrepancies between estimated and actual rows in several places. You also have hash matches all over the place. These are awfully big queries to have nothing more than an execution plan to unravel the performance issues. | |
| Jan 26, 2023 at 22:03 | history | asked | A Y B | CC BY-SA 4.0 |