I have a query that joins a dimension to a fact table. The fact table has a columnstore index on it. In my select clause I do a cast on a field from the dimension from a varchar to a date. One row in dimension with a key of -1 has values that would cause the cast to fail bc the string doesn't represent a valid date. I have in the where clause, where key <> -1 to filter out that 1 row. So I would assume the where clause would not return that row to the select statement and the cast would never happen against the invalid string. When I do a select with just the dimension, that is in fact how it behaves (no error). However, if I join that dimension to a fact table with a columnstore index, it fails on the conversion. If I drop that columnstore index and run the same query, it's fine. It's as if it's querying all of the dimension and doing the cast in the select before it's joining to the fact and applying the Where clause.I realize there are some design flaws here. We should probably use a try_convert, or simply store the date as a date field in the dimension. But I'd like to understand why it is behaving that way. We are starting to use columnstore indexes on all our fact tables with great benefits, but want to fully udnerstand these "gotchas". Do columnstore indexes change the order of operations? Where we just getting lucky with the execution plan that was chosen before the columnstore index applied? Thanks for the help.
↧