This class provides a mechansim to influence whether or not indexes are used for a
Filter during processing
by
QueryableIndexStorageAdapter.analyzeFilter(org.apache.druid.query.filter.Filter, org.apache.druid.segment.ColumnSelectorBitmapIndexSelector, org.apache.druid.query.QueryMetrics) (i.e. will a
Filter be a "pre"
filter in which we union indexes for all values that match the filter to create a
BitmapOffset/
BitmapVectorOffset, or will it
be used as a "post" filter and evaluated while scanning row values from the
FilteredOffset/
FilteredVectorOffset.
This is currently only manually supplied by the user by adding to a
DimFilter which will pass through to the
Filter implementation. The main purpose at this time is to facilitate experimentation so that someday we can
have
Filter implementations intelligently, automatically use sensible defaults based on things like
cardinality and who yet knows what additional information.
It can also be used for advanced users to manually control which filters will be "pre" and "post" filters as
described above to allow skipping indexes in known cases where filters are expensive (mostly high cardinality columns
with expensive filters).
As such, it is currently undocumented in user facing documentation on purpose, but whatever this turns into once more
automatic usage of this is in place, should be documented in a future release.