Package com.apple.foundationdb.record.provider.foundationdb.cursors

Class ProbableIntersectionCursor<T>

  • Type Parameters:
    T - the type of element returned by this cursor
    All Implemented Interfaces:
    RecordCursor<T>, AutoCloseable, Iterator<T>
    @API(EXPERIMENTAL)
public class ProbableIntersectionCursor<T>
extends MergeCursor<T,​T,​com.apple.foundationdb.record.provider.foundationdb.cursors.ProbableIntersectionCursorState<T>>
    A cursor that returns all results that are probably in all of its children. This differs from the IntersectionCursor in that it does not require that its children produce results in a compatible order. Just like the IntersectionCursor, this cursor does require a comparison key function for each entry, but it only uses this comparison key for determining whether two results returned by child cursors are equal.

    This cursor makes very few guarantees about its results. In particular, just as with the UnorderedUnionCursor, results are returned as they come, so the exact ordering of returned results is determined only at runtime. It also can produce duplicates if the same result appears multiple times in its child cursors. Additionally, in order to support resuming this cursor using a continuation, Bloom filters are used internally to remember which results the cursors have already seen. However, as Bloom filters can report false positives, it is possible that this cursor can return a result that only appears in a proper subset of the child cursors' result sets. The selectivity of the Bloom filter can be adjusted by setting the expectedResults and falsePositivePercentage parameters at cursor creation time. These parameters are fed through to the underlying Guava BloomFilter initializer.

    However, this cursor does make the following guarantees:

    • All results that are actually in the intersection will be in this cursor's result set.
    • Any result of this cursor is the result of at least one child cursor.

    This cursor can therefore be used to select a narrow candidate set of "probable" elements of the intersection and then perform a (possibly more expensive) alternative filter to verify each result. For example, if each child corresponds to satisfying some conjunct of an "and" predicate by scanning an index, then one could intersect the results with this cursor and then evaluate the predicate on each returned record as a residual filter.

    See Also:
    BloomFilter