On 3/16/23 02:24, Björn Häuser wrote:
1.) Are these equivalent field definitions?
Old:
<fieldType name="long" class="solr.TrieLongField" precisionStep="0"
positionIncrementGap="0”/>
New:
<fieldType name="long" class="solr.LongPointField" docValues="true”/>
I cannot find anything about precisionStep and positionIncrementGap for the new
fields and assume that docValues will take care of that in some way?
Replying to the initial email rather than the reply from Tomás, because
that reply did not maintain the headers for threading.
The precisionStep setting is something intrinsic to Trie types and is
not supported by Point types. It is a value related to speeding up
range queries, and a setting of zero essentially turns it off.
The positionIncrementGap setting really only makes sense for fields
using the TextField class. There's not really any such thing as a
phrase query for numeric types, which is where setting that increment
really makes a difference.
2.) Do we need to reindex after the scheme change?
We have a large collections and are serving requests 24/7. Is a full index
required or is Solr/Lucene able to handle both field types until everything is
updated?
Most indexing-related schema changes, including this one, require a full
reindex. If the schema uses Point types and the index contains Trie
types, it won't work. Problems could vary, from silent failure, partial
failure, throwing an exception, or even the index refusing to load. I
haven't tried it, so I am not familiar with what actually happens.
Side note: The Point types are a LOT slower at simple field:value
queries than Trie, but Trie is deprecated and will be removed. They've
been deprecated since version 6, so they might already be removed.
Point types are really good at range queries though, so if you change
that to "field:[value TO value]" it should be fast.
Thanks,
Shawn
