[
https://issues.apache.org/jira/browse/CALCITE-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6704:
------------------------------------
Labels: pull-request-available (was: )
> Add limit parameter to restrict the result size of UniqueKeys metadata
> ----------------------------------------------------------------------
>
> Key: CALCITE-6704
> URL: https://issues.apache.org/jira/browse/CALCITE-6704
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.38.0
> Reporter: Stamatis Zampetakis
> Assignee: Stamatis Zampetakis
> Priority: Major
> Labels: pull-request-available
>
> In some cases, the number of unique keys grows exponentially for certain
> relational expressions.
> Consider a table with a composite key \{k1, k2, k3\} and the following query:
> {code:sql}
> SELECT k1, k1, k2, k2, k3, k3 FROM composite
> {code}
> The number of minimal unique keys for this query is 2^3:
> {noformat}
> {0, 2, 4}, {0, 3, 4}, {1, 2, 4}, {1, 3, 4}, {0, 2, 5}, {0, 3, 5}, {1, 2, 5},
> {1, 3, 5}
> {noformat}
> In this case, the size of *minimal keys* is exponential to the number of
> columns in the composite key. The number of keys is f(x,y) = x^y where _x_ is
> the number of repetitions of each column and _y_ is the number of columns in
> the composite key. The example is taken out from CALCITE-6640.
> A large number of unique keys may occur in other use-cases as well. Computing
> the entire result set may become prohibitively expensive and cause OOM and
> other failures.
> To prevent this from happening we propose to add a new parameter to the
> UniqueKeys interface allowing the users to specify a limit on the size of
> the result set.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
