Query Options
This document contains all the available query options
Supported Query Options
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)
false (disabled)
explainPlanVerbose
Return verbose result for EXPLAIN query (introduced in 0.11.0)
false (not verbose)
useMultistageEngine
Use multi-stage engine to execute the query (introduced in 0.11.0)
false (use single-stage engine)
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)
1 (only query servers within the same replica-group)
sortAggregateLimitThreshold
For group-by query, in case of ordering by all group keys, use sort-aggregation when query LIMIT is below this threshold. Under such cases, sort-aggregation allows trimming that does not affect result correctness, and is often more efficient than hash aggregation due to significantly reduced memory pressure. Example query that uses sort-aggregation: SELECT col1, COUNT(*) FROM t1 GROUP BY col1, col2 ORDER BY col1, col2 DESC LIMIT X; , where X is smaller than this threshold.
10000
sortAggregateSingleThreadedNumSegmentsThreshold
When sort-aggregation is used under the above cases described in sortAggregateLimitThreshold, use single-threaded sequential combine instead of parallel pair-wise combine when the number of segments to merge is below this threshold.
Number of CPU cores
minSegmentGroupTrimSize
Minimum groups to keep when trimming groups at the segment level for group-by queries. See Grouping Algorithm
Server level config
minServerGroupTrimSize
Minimum groups to keep when trimming groups at the server level for group-by queries. See Grouping Algorithm
Server level config
serverReturnFinalResult
For aggregation and group-by queries, ask servers to directly return final results instead of intermediate results for aggregations. Can be applied when the group key is server partitioned, i.e. the column(s) is partitioned, and all the data for a partition is served by the same server.
true when a single server is queried, false otherwise
serverReturnFinalResultKeyUnpartitioned
For group-by queries, ask servers to directly return final results instead of intermediate results for aggregations. Different from serverReturnFinalResult, this option should be used when the group key is not server partitioned, but the aggregated column is server partitioned. It is particularly useful for distinct count queries. When this option is enabled, server will return final results, but won't directly trim the result to the query limit.
false
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: skipIndexes='col1=inverted,range&col2=inverted'
Possible index types to skip are: sorted, range, inverted, H3. To find out which indexes are used to resolve a given query, use the EXPLAIN query.
null/empty (use all available indexes)
skipPlannerRules
Which defaultly enabled query planner rules should be disabled. This is useful when EXPLAIN PLAN FOR suggests a rule evaluation is taking too long or when it is known that a rule produces sub-optimal plan for the query. Currently this only applies to rules in optProgram that are mostly logical transformations.
Config can be specified using rule names delimited by comma: skipPlannerRules='FilterProjectTranspose,PruneEmptySort'
The rule name used here is consistent with the output of EXPLAIN PLAN FOR, which is the rule description.
null/empty (no defaultly enabled rules are skipped)
usePlannerRules
Which query planner rules that are disabled by default should be used. This is useful when the defaultly disabled rules could help query execution.
Config can be specified using rule names delimited by comma: usePlannerRules='AggregateJoinTransposeExtended,JoinToEnrichedJoin'. This query option only applies to the set of defaultly disabled rules listed in https://github.com/pinot-contrib/pinot-docs/blob/latest/users/user-guide-query/default-disabled-rules.md
At this point, Pinot does not have a cost-based optimizer and the multi-stage query engine uses Calcite's HepPlanner for query optimization. The rules that are disabled by default are those that are only helpful under certain circumstances. For a more detailed description on what these rules do and when are they helpful, please see https://github.com/pinot-contrib/pinot-docs/blob/latest/users/user-guide-query/default-disabled-rules.md.
null/empty (no defaultly disabled rules are used)
skipUpsert
For upsert-enabled table, skip the effect of upsert and query all the records. See Stream Ingestion with Upsert
false (exclude the replaced records)
useStarTree
Useful to debug the star-tree index (introduced in 0.11.0)
true (use star-tree if available)
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
false (values in IN predicate is not pre-sorted)
inPredicateLookupAlgorithm
(Only apply to STRING columns) The algorithm to use to look up the dictionary ids for the IN clause values.
DIVIDE_BINARY_SEARCH: Sort the IN clause values and do binary search on both dictionary and IN clause values at same time to reduce the value lookupsSCAN: Sort the IN clause values and scan both dictionary and IN clause values to get the matching dictionary idsPLAIN_BINARY_SEARCH: Do not sort the IN clause values, but directly binary search each IN clause value in the dictionary
DIVIDE_BINARY_SEARCH
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
filteredAggregationsSkipEmptyGroups
This config can be set to true to avoid computing all the groups in a group by query with only filtered aggregations (and no non-filtered aggregations). By default, the groups are computed over all the rows returned by the main filter, even if certain rows will never match any of the aggregation filters. This is the standard SQL behavior. However, if the selectivity of the main filter is very high as compared to the selectivity of the aggregation filters, this query option can help provide a big performance boost if the empty groups aren't required. For instance, a query like SELECT SUM(X) FILTER (WHERE Y = 1) FROM mytable will compute the groups over all the rows in the table by default since there's no main query filter. Setting this query option to true in such cases can massively improve performance if there's an inverted index on column Y for instance.
false (i.e., all groups are computed by default as per standard SQL)
dropResults
Set dropResults=true in the config to drop the resultTable from the response. Use this option to troubleshoot a customer's query (which may have sensitive data in the result) using metadata only.
false
skipUnavailableServers
Set skipUnavailableServers=true in the config to continue sending queries to remaining servers if dispatching a query fails.
false
accurateGroupByWithoutOrderBy
Improves correctness of group-by queries with LIMIT but without ORDER BY by applying better trimming on servers. See PR #15844. Set accurateGroupByWithoutOrderBy=true to enable
false (disabled)
traceRuleProductions
Trace planner rule productions. Specify SET traceRuleProductions=true to collect and return planner rules that successfully produced new relations and the relation subtree before and after the production in time order along with rule attempt timing. Useful for debugging query planning.
false
excludeVirtualColumns
When you want to ignore virtual columns (those starting with $) in a query — such as a NATURAL JOIN where they shouldn't be participating in join condition matching. This option helps remove all virtual columns from the schema during query planning and execution making NATURAL JOIN successful. This is currently implemented in MSE.
false (virtual columns are included by default for all queries during join-match)
usePhysicalOptimizer
Enable the Physical Optimizer for the multi-stage engine (MSE). The Physical Optimizer can automatically eliminate or simplify redundant Exchanges (shuffles) for arbitrarily complex queries without requiring query hints. Must be used with useMultistageEngine=true. See Physical Optimizer for details. (introduced in 1.4.0, Beta)
false (disabled)
useLiteMode
Enable Multistage Engine Lite Mode, which runs MSE queries using a scatter-gather paradigm (like the single-stage engine) with a configurable limit on rows returned by each leaf stage instance (default 100k). This allows safe access to MSE features like window functions, subqueries, and joins at high QPS with minimal reliability risks. Requires both useMultistageEngine=true and usePhysicalOptimizer=true. See Multistage Lite Mode for details. (introduced in 1.4.0, Beta)
false (disabled)
orderedPreferredPools
Specify a prioritized list of server pools for broker query routing, provided as a vertical bar (|) separated list of pool identifiers (integers). The broker uses the list as a routing hint, attempting to route queries to the specified pools in order and falling back gracefully to other available replicas if none of the preferred pools are available. Useful for canary deployments where directing traffic to specific replica groups is desired. Currently supported for Balanced and ReplicaGroup routing strategies with Adaptive Server Selection in non-MSE mode. (introduced in 1.4.0)
null/empty (no pool preference; use default routing)
workloadName
Assigns the query to a named workload for resource budget enforcement. Requires the workload query scheduler. See Workload-Based Query Resource Isolation (introduced in 1.4.0)
null/empty (query belongs to the default workload with no budget enforcement)
isSecondaryWorkload
Marks the query as a secondary workload query. With the binary_workload scheduler, secondary queries run with limited threads. With the workload scheduler, maps to the configured secondary workload budget. See Workload-Based Query Resource Isolation (introduced in 1.4.0)
false
Cursor Pagination
getCursor
When set to true, a cursor is returned instead of the complete result set. This allows clients to fetch query results incrementally, which is useful for large result sets.
false (return full result set)
cursorNumRows
Number of rows each cursor page should contain. Only applies when getCursor=true.
Broker level config
Explain Plan
explainAskingServers
Controls the explain behavior in the multi-stage engine. When set to true, servers are asked to return the physical plan. When false, only the logical plan is returned (mimics behavior of Pinot 1.2.0 and earlier).
true
Group-By Trim
minBrokerGroupTrimSize
Minimum number of groups to keep when trimming groups at the broker level for group-by queries (SSE only). Similar to minSegmentGroupTrimSize and minServerGroupTrimSize but applied at the broker reduce phase. Setting to a non-positive value disables broker-level trim. See Grouping Algorithm
Broker level config (default 5000)
groupTrimThreshold
Threshold for group-by trimming at the broker level. Controls the maximum number of groups that can be held before trimming is triggered during the broker reduce phase.
Broker level config (default 1000000)
Join and Window Overflow
joinOverflowMode
Controls behavior when a join operation exceeds maxRowsInJoin. Possible values: THROW (throw an exception) or BREAK (stop processing and return partial results).
THROW
maxRowsInWindow
Configure maximum rows allowed in a window function operation. This helps prevent excessive memory usage when processing large window frames.
Default value read from cluster config pinot.query.window.max.rows; if not set, defaults to 2^20 (1024*1024)
windowOverflowMode
Controls behavior when a window operation exceeds maxRowsInWindow. Possible values: THROW (throw an exception) or BREAK (stop processing and return partial results).
THROW
Multi-Cluster Routing
enableMultiClusterRouting
When enabled, allows multi-cluster/federated queries to be executed. This routes queries across multiple Pinot clusters.
false (disabled)
Broker Pruning
useBrokerPruning
When set to true, enables broker-side segment pruning logic in the multi-stage engine. This allows the broker to prune segments before dispatching queries to servers, reducing unnecessary computation. Only supported by the MSE query optimizer.
Broker level config (default true)
Last updated
Was this helpful?