[
https://issues.apache.org/jira/browse/SOLR-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15087105#comment-15087105
]
Modassar Ather commented on SOLR-7954:
--------------------------------------
{noformat}q=fl1:net*&facet.field=fl&facet.limit=50&stats=true&stats.field={!cardinality=1.0}fl{noformat}
Above query is returning cardinality around 15 million. It is taking around 4
minutes. Similar response time is seen with different queries which yields high
cardinality. Kindly note that the cardinality=1.0 is the desired goal.
Here in the above example the fl1 is a text field whereas fl is a docValue
enabled non-stroed, non-indexed field.
Kindly let me know if such response time is expected or I am missing something
about this feature in my query.
> ArrayIndexOutOfBoundsException from distributed HLL serialization logic when
> using using stats.field={!cardinality=1.0} in a distributed query
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-7954
> URL: https://issues.apache.org/jira/browse/SOLR-7954
> Project: Solr
> Issue Type: Bug
> Affects Versions: 5.2.1
> Environment: SolrCloud 4 node cluster.
> Ubuntu 12.04
> OS Type 64 bit
> Reporter: Modassar Ather
> Assignee: Hoss Man
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7954.patch, SOLR-7954.patch, SOLR-7954.patch
>
>
> User reports indicate that using {{stats.field=\{!cardinality=1.0\}foo}} on a
> field that has extremely high cardinality on a single shard (example: 150K
> unique values) can lead to "ArrayIndexOutOfBoundsException: 3" on the shard
> during serialization of the HLL values.
> using "cardinality=0.9" (or lower) doesn't produce the same symptoms,
> suggesting the problem is specific to large log2m and regwidth values.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]