[ 
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to