Nevermind- I think I may have had a schema-related issue (sometimes booleans were represented as string and sometimes as raw booleans but when I populated the schema one or the other was chosen.
On Fri, Feb 13, 2015 at 8:03 PM, Corey Nolet <[email protected]> wrote: > Here are the results of a few different SQL strings (let's assume the > schemas are valid for the data types used): > > SELECT * from myTable where key1 = true -> no filters are pushed to my > PrunedFilteredScan > SELECT * from myTable where key1 = true and key2 = 5 -> 1 filter (key2) is > pushed to my PrunedFilteredScan > SELECT * from myTable where key1 = false and key3 = 'val3' -> 1 filter > (key3) is pushed to my PrunedFilteredScan > SELECT * from myTable where key1 = 'false' -> (as expected) it passed down > an EqualTo Filter that's matching 'false' as a string. > > > I was going to file a bug for this but before I did that I wanted to make > sure I wasn't missing something (like a special way to handle booleans). > I'm assuming the filter is being optimized out because it's being assigned > the literal "true" but in this case I really want to match against a > boolean datatype which is true. > > >
