Query Partitions
A query partition consists of a group of database forests that share the same name prefix and the same query assignment policy described in Query Assignment Policy.
Note
Query partitions query documents in an unfiltered manner. For details about unfiltered queries, see the Fast Pagination and Unfiltered Searches in the Query Performance and Tuning Guide.
Each query partition is associated with a query that determines which documents are stored in that partition. When creating a query partition, you assign it a partition number. Unlike range partitions, queries set for partitions using the query assignment policy can have “overlaps,” so that a document may be matched by the query set for more than one partition. In the event of an overlap, the partition with the lower number is selected over partitions with higher numbers.
Note
As is the case with range assignment policy, you should define a default partition when configuring the query assignment policy. If you do not define a default partition, the database forests that are not associated with a query partition are used.
For example, you have three query partitions, a default partition and two partitions associated with the following types of queries:
Query Partition 1: (Default -- no query)
Query Partition 2:
Requirement |
Query Type |
|---|---|
the author includes "Twain" |
word |
there is a paperback edition |
value |
the price of the paperback edition is less than $9.00 |
range |
Query Partition 3:
Requirement |
Query Type |
|---|---|
the title includes “Adventures” |
word |
the characters include “Huck” |
word |
the class is “fiction” |
word |
In this example, the document “Adventures of Huckleberry Finn” matches both queries, but is stored in Query Partition 2 because it is the partition with the lower number. On the other hand, the document “Moby Dick” does not match either query, so it is stored in Partition 1, the Default Query Partition.