somu-imply commented on a change in pull request #12195:
URL: https://github.com/apache/druid/pull/12195#discussion_r804925212
##########
File path: docs/querying/query-context.md
##########
@@ -62,7 +62,7 @@ Unless otherwise noted, the following parameters apply to all
query types.
|secondaryPartitionPruning|`true`|Enable secondary partition pruning on the
Broker. The Broker will always prune unnecessary segments from the input scan
based on a filter on time intervals, but if the data is further partitioned
with hash or range partitioning, this option will enable additional pruning
based on a filter on secondary partition dimensions.|
|enableJoinLeftTableScanDirect|`false`|This flag applies to queries which have
joins. For joins, where left child is a simple scan with a filter, by default,
druid will run the scan as a query and the join the results to the right child
on broker. Setting this flag to true overrides that behavior and druid will
attempt to push the join to data servers instead. Please note that the flag
could be applicable to queries even if there is no explicit join. since queries
can internally translated into a join by the SQL planner.|
|debug| `false` | Flag indicating whether to enable debugging outputs for the
query. When set to false, no additional logs will be produced (logs produced
will be entirely dependent on your logging level). When set to true, the
following addition logs will be produced:<br />- Log the stack trace of the
exception (if any) produced by the query |
-
+|maxNumericInFilters|`-1`|Max limit for the amount of numeric values that can
be compared for a string type dimension when the entire SQL WHERE clause of a
query translates to an [IN filter](../querying/filters.md#in-filter). By
default, Druid does not restrict the amount of numbers in an IN filter,
although this situation may block other queries from running. Set this property
to a smaller value to prevent Druid from running queries that have
prohibitively long segment processing times. The optimal limit requires some
trial and error; we recommend starting with 100. Users who submit a query that
exceeds the limit of `maxNumericInFilters` should instead rewrite their queries
to use strings in the IN filter instead of numbers. For example, `WHERE
someString IN (‘123’, ‘456’)`. This value cannot exceed the set system
configuration `druid.sql.planner.maxNumericInFilters`. This value is ignored if
`druid.sql.planner.maxNumericInFilters` is not set explicitly.|
Review comment:
As discussed docs updated indicating that it supports only ORs of IN
filters
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
