Hi All,
I'm new to solr development. Since I'm new with the code base, I thought
I'd double check here before making a JIRA issue. We're trying to use
grouping on a field with a type of long (on trunk):
<fieldType name="long" class="solr.TrieLongField" precisionStep="0"
omitNorms="true" positionIncrementGap="0"/>
The performance wasn't what we were looking for so I'm taking a quick
look at the grouping code in solr and I noticed that a string field uses
the Term grouping classes (CommandField in
/trunk/solr/core/src/java/org/apache/solr/search/Grouping.java).
However, when using a long field the Function grouping classes get used
(CommandFunc in
/trunk/solr/core/src/java/org/apache/solr/search/Grouping.java). When I
change it over to using CommandField instead of CommandFunc for long
type I get a decrease in QTime (I only did light testing, and just
simple queries but it seemed to drop by 50% or so).
The functionality appears to still work and the grouping tests pass, but
as I'm not very familiar with the solr code I wasn't sure if there was a
reason for Long to use CommandFunc instead of CommandField.
I'm happy to take a stab at making a JIRA issue and a patch if this is
indeed an issue, but I'll need some guidance on the best way to fix this
(perhaps instead of using instanceof StrFieldSource or instanceof
LongFieldSource there is a better way to check?).
The change I made to test this was very simple, I just added:
import org.apache.lucene.queries.function.valuesource.LongFieldSource;
and at Line 176 of Grouping.java
} else if(valueSource instanceof LongFieldSource) {
String field = ((LongFieldSource) valueSource).getField();
CommandField commandField = new CommandField();
commandField.groupBy = field;
gc = commandField;
Thanks,
Cody
