Not only .t./.f.: if I find fields with 1..4 values, combining 2 binary indices like IsOdd and IsLow can give you better perf if used often in filtering, as only 1 bit per record (the resulting Rushmore "map") is persisted and combined in filtering, reducing index size like crazy.

>But all a good discussion - I have never used a binary index and so had to look it up. Might come in handy some day if there is a true/false answer on a field expression.
>Thanks!
>
>>You read my mind via my not well formulated question perfectly!
>>Binary Index should speed up that particular subquery, but if empty(partfile.Date_Closd ) is not used elsewhere in table filtering operations, your current approach probably is best, as overindexing produces its own pain points.
>>
>>regards
>>thomas
>>
>>>It is non-nullable. Have a machine index, not binary. The index is used in other ad-hoc queries where the users can specify a closing date range. Binary would just be for indexing if empty or not correct (at least that is what I am guessing you are getting at).
>>>
>>>Albert
>>>
>>>>Hmmm, seems to big a win - did you have a BINARY INDEX on partfile.Date_Closd ?
>>>>(guessing that this is non-nullable)
>>>>
>>>>>Made the changes and that indeed worked better and faster.