[
https://issues.apache.org/jira/browse/SOLR-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585495#comment-15585495
]
Yonik Seeley commented on SOLR-9599:
------------------------------------
Here's a more thorough/accurate (not by-hand) sorting test on the same index
above (docvalue fields, 10M docs, 80% value density).
Base query = *:*, 4 query threads, finding top 10 documents.
Representative query:
q={!cache%3Dfalse}*:*&fl=id&sort=s10_i+asc,s1000000_i+desc&rows=10&wt=javabin
Results below in new_time/old_time:
{code}
one string sort field (fields have cardinality of 10,100,1000,10000,100000, or
1000000): 1.20
2 string sort fields, first has cardinality of 10 or 100: 1.27
2 integer sort fields, first has cardinality of 10 or 100: 1.46
{code}
> DocValues performance regression with new iterator API
> ------------------------------------------------------
>
> Key: SOLR-9599
> URL: https://issues.apache.org/jira/browse/SOLR-9599
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: master (7.0)
> Reporter: Yonik Seeley
> Fix For: master (7.0)
>
>
> I did a quick performance comparison of faceting indexed fields (i.e.
> docvalues are not stored) using method=dv before and after the new docvalues
> iterator went in (LUCENE-7407).
> 5M document index, 21 segments, single valued string fields w/ no missing
> values.
> || field cardinality || new_time / old_time ||
> |10|2.01|
> |1000|2.02|
> |10000|1.85|
> |100000|1.56|
> |1000000|1.31|
> So unfortunately, often twice as slow.
> See followup messages for tests using real docvalues as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
