t; To: solr-user@lucene.apache.org
> Subject: Re: Clarification on term facet method dvhash
>
> Correction!: wrt "dvhash" and numeric types, it looks like I had it exactly
> backwards! single-valued numeric types _do_ use (even default to) "dvhash"
> ... sorry a
: solr-user@lucene.apache.org
Subject: Re: Clarification on term facet method dvhash
Correction!: wrt "dvhash" and numeric types, it looks like I had it exactly
backwards! single-valued numeric types _do_ use (even default to) "dvhash"
... sorry about that! I stand by the
Correction!: wrt "dvhash" and numeric types, it looks like I had it exactly
backwards! single-valued numeric types _do_ use (even default to) "dvhash"
... sorry about that! I stand by the rest of the previous message though,
which applies at a minimum to string-like fields.
On Fri, Feb 5, 2021 at
> Performance and resource is still affected by 30M unique values of T
right?
Yes. The main performance issue would be the per-request allocation of a
30M-element `long[]` for "dv" or "uif" methods (which are by far the most
common methods in practice). With low enough request volume and large
enou
Hello,
I’m using Solr 8.4. Very excited about performance improvements in 8.8:
http://joelsolr.blogspot.com/2021/01/optimizations-coming-to-solr.html
As I understand the main determinator of performance and RAM usage of a terms
facet is cardinality of the field in whole collection, but not the
