[
https://issues.apache.org/jira/browse/SOLR-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16177213#comment-16177213
]
Varun Thacker commented on SOLR-10939:
--------------------------------------
I was doing some benchmarking of the "join" domain switch feature and I
discovered something interesting .
Essentially I am doing a 3 level nested facet. Top two levels ask for the top
10 and the third level does a join domain switch . So a 100 joins .
For a 3M data set in one shard , queries always take ~66 seconds when executing
the join domain on a string field. When executed on a int point field it takes
4/5 seconds. So that's more than a 10x speedup
Currently how the implementation works is it rewrites the query to a
GraphPointsCollector when it's a points field . It uses
{{JoinQParserPlugin#getDocSetEnumerate}} otherwise.
I'm wondering if we would see similar improvements if we could move non point
fields to use GraphTermsCollector instead ? I am posting this comment without
investigating if it's even possible. If it is I'll create a separate jira. Any
thoughts?
> JoinQParser gives incorrect results with numeric PointsFields
> -------------------------------------------------------------
>
> Key: SOLR-10939
> URL: https://issues.apache.org/jira/browse/SOLR-10939
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Yonik Seeley
> Priority: Blocker
> Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-10939.patch
>
>
> If you try to use the {{\{!join\}}} QParser with numeric points fields, you
> will get silently incorrect results.
> The underlying root cause seems to be that JoinQParser's JoinQuery assumes
> every field it's dealing with has indexed terms. (AFAICT it won't even work
> with {{indexed="false" docValues="true"}} Trie fields????)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
