Query Options
This document contains all the available query options
Supported Query Options
Key | Description | Default Behavior |
---|---|---|
timeoutMs | Timeout of the query in milliseconds | Use table/broker level timeout |
enableNullHandling | Enables advanced null handling. See Null value support for more information.(introduced in 0.11.0) |
|
explainPlanVerbose | Return verbose result for |
|
useMultistageEngine | Use multi-stage engine to execute the query (introduced in 0.11.0) |
|
maxExecutionThreads | Maximum threads to use to execute the query. Useful to limit the resource usage for expensive queries | Half of the CPU cores for non-group-by queries; all CPU cores for group-by queries |
numReplicaGroupsToQuery | When replica-group based routing is enabled, use it to query multiple replica-groups (introduced in 0.11.0) |
|
minSegmentGroupTrimSize | Server level config | |
minServerGroupTrimSize | Server level config | |
skipIndexes | Which indexes to skip usage of (i.e. scan instead), per-column. This is useful for side-by-side comparison/debugging. There can be cases where the use of an index is actually more expensive than performing a scan of the docs which match other filters. One such example could be a low-selectivity inverted index used in conjunction with another highly selective filter. Config can be specified using url parameter format: Possible index types to skip are: |
|
skipUpsert | For upsert-enabled table, skip the effect of upsert and query all the records. See Stream ingestion with Upsert |
|
useStarTree | Useful to debug the star-tree index (introduced in 0.11.0) |
|
AndScanReordering | disabled | |
maxRowsInJoin | Configure maximum rows allowed in a join operation. This limit is applied to both the hash table build phase for the join's right input as well as the number of joined rows emitted after matching with the join's left input. | default value read from cluster config if not set, the default will be 2^20 (1024*1024) |
inPredicatePreSorted | (Only apply to STRING columns) Indicates that the values in the IN clause is already sorted, so that Pinot doesn't need to sort them again at query time |
|
inPredicateLookupAlgorithm | (Only apply to STRING columns) The algorithm to use to look up the dictionary ids for the IN clause values.
|
|
maxServerResponseSizeBytes | Long value config indicating the maximum length of the serialized response per server for a query. | Overriding priortiy order: 1. QueryOption -> maxServerResponseSizeBytes 2. QueryOption -> maxQueryResponseSizeBytes 3. TableConfig -> maxServerResponseSizeBytes 4. TableConfig -> maxQueryResponseSizeBytes 5. BrokerConfig -> maxServerResponseSizeBytes 6. BrokerConfig -> maxServerResponseSizeBytes |
maxQueryResponseSizeBytes | Long value config indicating the maximum serialized response size across all servers for a query. This value is equally divided across all servers processing the query. | Overriding priortiy order: 1. QueryOption -> maxServerResponseSizeBytes 2. QueryOption -> maxQueryResponseSizeBytes 3. TableConfig -> maxServerResponseSizeBytes 4. TableConfig -> maxQueryResponseSizeBytes 5. BrokerConfig -> maxServerResponseSizeBytes 6. BrokerConfig -> maxServerResponseSizeBytes |
Set Query Options
SET statement
After release 0.11.0, query options can be set using the SET
statement:
OPTION keyword (deprecated)
Before release 0.11.0, query options can be appended to the query with the OPTION
keyword:
REST API
Query options can be specified in API using queryOptions as key and ';' separated key-value pairs. Alternatively, we can also use the SET keyword in the sql query.
Last updated