Timeline for Same query way faster with distinct than without distinct
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 7, 2020 at 22:23 | history | edited | CommunityBot |
added [query-performance] to 2412 questions - Shog9 (Id=1924)
|
|
| Nov 14, 2019 at 17:33 | comment | added | Marcello Miorelli | have you go up to date statistics? | |
| Sep 29, 2017 at 14:08 | comment | added | Florent.K | Thank you, David, for your inputs. Sorry, I am just reacting now because I was busy on a mission. Just like you, I am also wondering why the query without distinct is not seeking the index. I am a part time employee at the customer with this behavior. And the customer asks for many tasks. If I have a chance, I will try to provide keys and indexes definitions on those tables. | |
| Sep 20, 2017 at 11:18 | answer | added | Scott Hodgin - Retired | timeline score: 2 | |
| Sep 20, 2017 at 9:32 | comment | added | David Spillett |
Assuming the second plan is significantly more efficient when actually run and the results are identical, I'm not sure why the planner is not seeing the optimisation without DISTINCT being present. It may help to know what keys and indexes are defined on those tables so I suggest editing that information into the question. Though as the first plan is scanning ~400K and ~4M rows from the Add_Remove_* tables, if DisplayName00 = 'aze' is particularly selective it could help that plan massively to have an index on each of those columns, perhaps INCLUDEing MachineID'.
|
|
| Sep 20, 2017 at 8:35 | review | First posts | |||
| Sep 20, 2017 at 9:02 | |||||
| Sep 20, 2017 at 8:31 | history | edited | ypercubeᵀᴹ | CC BY-SA 3.0 |
added 1236 characters in body; edited tags
|
| Sep 20, 2017 at 8:26 | history | edited | Florent.K | CC BY-SA 3.0 |
added 85 characters in body
|
| Sep 20, 2017 at 8:21 | history | asked | Florent.K | CC BY-SA 3.0 |