Join cursors provide a way to iterate over a subset of a table, where the subset is specified by relationships with reference cursors.
A join cursor is created with WT_SESSION::open_cursor using a
"join:table:<name>" URI prefix. Then reference cursors are positioned to keys on indices and joined to the join cursor using WT_SESSION::join calls. The result is a join cursor that can be iterated to satisfy the join equation.
Here is an example using join cursors:
Joins support various comparison operators:
"le". Ranges with lower and upper bounds can also be specified, by joining two cursors on the same index, for example, one with
"compare=ge" and another
"compare=lt". In addition to joining indices, the main table can be joined so that a range of primary keys can be specified.
By default, a join cursor returns a conjunction, that is, all keys that satisfy all the joined comparisons. By specifying a configuration with
"operation=or", a join cursor will return a disjunction, or all keys that satisfy at least one of the joined comparisons. More complex joins can be composed by specifying another join cursor as the reference cursor in a join call.
Here is an example using these concepts to show a conjunction of a disjunction:
All the joins should be done on the join cursor before WT_CURSOR::next is called. Calling WT_CURSOR::next on a join cursor for the first time populates any bloom filters and performs other initialization. The join cursor's key is the primary key (the key for the main table), and its value is the entire set of values of the main table. A join cursor can be created with a projection by appending
"(col1,col2,...)" to the URI if a different set of values is needed.
Keys returned from the join cursor are ordered according to the first reference cursor joined. For example, if an index cursor was joined first, that index determines the order of results. If the join cursor uses disjunctions, then the ordering of all joins determines the order. The first join in a conjunctive join, or all joins in a disjunctive join, are distinctive in that they are iterated internally as the cursor join returns values in order. Any bloom filters specified on the joins that are used for iteration are not useful, and are silently ignored.
When disjunctions are used where the sets of keys overlap on these 'iteration joins', a join cursor will return duplicates. A join cursor never returns duplicates unless
"operation=or" is used in a join configuration, or unless the first joined cursor is itself a join cursor that would return duplicates.