[
https://issues.apache.org/jira/browse/SOLR-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199598#comment-15199598
]
Ishan Chattopadhyaya commented on SOLR-8082:
--------------------------------------------
bq. Building a boolean query is the slowest option of all (will look up all the
values twice and has overhead)... coverting to a float/double would be faster
Do you mean that instead of using the DocValuesRangeQuery.newLongRange(), we
write something on our own which converts the longs back to floats/doubles and
then compares those floats/doubles?
bq. If we did want to keep things in "long" space rather than converting, then
perhaps just create our own version that does an additional comparison when
needed.
Do you think the NumericUtils.doubleToSortableLong() is a good choice for
converting float/double to longs, instead of Double.doubleToLongBits() which is
currently used? I think this would ensure that the range queries would just
work out of the box without such handling of special cases. Also, is it okay to
change the way we convert floats/doubles to longs in terms of backward
compatibility?
> can't query against negative float or double values when indexed="false"
> docValues="true" multiValued="false"
> -------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8082
> URL: https://issues.apache.org/jira/browse/SOLR-8082
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Attachments: SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch,
> SOLR-8082.patch, SOLR-8082.patch, SOLR-8082.patch
>
>
> Haven't dug into this yet, but something is evidently wrong in how the
> DocValues based queries get build for single valued float or double fields
> when negative numbers are involved.
> Steps to reproduce...
> {noformat}
> $ bin/solr -e schemaless -noprompt
> ...
> $ curl -X POST -H 'Content-type:application/json' --data-binary '{
> "add-field":{ "name":"f_dv_multi", "type":"tfloat", "stored":"true",
> "indexed":"false", "docValues":"true", "multiValued":"true" }, "add-field":{
> "name":"f_dv_single", "type":"tfloat", "stored":"true", "indexed":"false",
> "docValues":"true", "multiValued":"false" } }'
> http://localhost:8983/solr/gettingstarted/schema
> {
> "responseHeader":{
> "status":0,
> "QTime":84}}
> $ curl -X POST -H 'Content-type:application/json' --data-binary
> '[{"id":"test", "f_dv_multi":-4.3, "f_dv_single":-4.3}]'
> 'http://localhost:8983/solr/gettingstarted/update/json/docs?commit=true'
> {"responseHeader":{"status":0,"QTime":57}}
> $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:"-4.3";'
> {
> "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
> "q":"f_dv_multi:\"-4.3\""}},
> "response":{"numFound":1,"start":0,"docs":[
> {
> "id":"test",
> "f_dv_multi":[-4.3],
> "f_dv_single":-4.3,
> "_version_":1512962117004689408}]
> }}
> $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:"-4.3";'
> {
> "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
> "q":"f_dv_single:\"-4.3\""}},
> "response":{"numFound":0,"start":0,"docs":[]
> }}
> {noformat}
> Explicit range queries (which is how numeric "field" queries are implemented
> under the cover) are equally problematic...
> {noformat}
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:%5B-4.3+TO+-4.3%5D'
> {
> "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
> "q":"f_dv_multi:[-4.3 TO -4.3]"}},
> "response":{"numFound":1,"start":0,"docs":[
> {
> "id":"test",
> "f_dv_multi":[-4.3],
> "f_dv_single":-4.3,
> "_version_":1512962117004689408}]
> }}
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:%5B-4.3+TO+-4.3%5D'
> {
> "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
> "q":"f_dv_single:[-4.3 TO -4.3]"}},
> "response":{"numFound":0,"start":0,"docs":[]
> }}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
