3 ms·
This feels like a bug in the SQL query optimizer rather than Dapper. It ought to be smart enough to convert a constant parameter to the target column type in a
by jiggawatts 8mo ago
This feels like a bug in the SQL query optimizer rather than Dapper.
It ought to be smart enough to convert a constant parameter to the target column type in a predicate constraint and then check for the availability of a covering index.
- wvenable 8mo agoIt's the optimizer caching the query plan as a parameterized query. It's not re-planning the index lookup on every execution.
- SigmundA 8mo agoThe parameter type is part of the cache identity, nvarchar and varchar would have two cache entries with possibly different plans.
- deleted 8mo ago[deleted]
- valiant55 8mo agoThere's a data type precedence that it uses to determine which value should be casted[0]. Nvarchar is higher precedence, therefore the varchar value is "lifted" to an nvarchar value first. This wouldn't be an issue if the types were reversed. 0: https://learn.microsoft.com/en-us/sql/t-sql/data-types/data-type-precedence-transact-sql?view=sql-server-ver17 https://learn.microsoft.com/en-us/sql/t-sql/data-types/data-...
- Sankozi 8mo agoSo such issues can appear in more products and more datatypes (int and bigint have same problem). This is really bad rule for SQL's "equality" operator. Still optimizer should be able to handle it - if the result is the same, optimizer should take faster path.
- beart 8mo agoHow do you safely convert a 2 byte character to a 1 byte character?
- jiggawatts 8mo agoEasily! If it doesn't convert successfully because it includes characters outside of the range of the target codepage then the equality condition is necessarily false, and the engine should short-circuit and return an empty set.