Timeline for Query is slow with JDBC parameters, fast with concatenated SQL
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 28, 2019 at 21:44 | comment | added | Dana | I voted this up because it helped me diagnose, but didn't select it because it didn't solve the problem. | |
| Mar 5, 2019 at 14:55 | history | edited | David Browne - Microsoft | CC BY-SA 4.0 |
added 237 characters in body
|
| Mar 5, 2019 at 13:04 | comment | added | David Browne - Microsoft | It’s also guessing about the average number of rows that make it this far. If there are a large number of rows to check, scanning the index will be cheaper. | |
| Mar 5, 2019 at 4:49 | comment | added | Dana | "Apparently it's guessing you will often have a selective LIKE predicate, and so using the Name index will, on average, be cheaper. " This seems like a really bad call given that a LIKE predicate could have a wildcard at the front, and the table is big… | |
| Mar 5, 2019 at 1:44 | history | answered | David Browne - Microsoft | CC BY-SA 4.0 |