You have it reversed Jason -- Points (based on BKD index) excel at range queries. Exact match (what you call single-lookup) is okay but not great. Trie does both well but pays a higher indexing cost to do it. The advice given back then (from Adrien, I recall) was to use the Lucene standard terms index for exact match, and BKD for range -- thus 2 fields or at least index structures. Unfortunately in Solr we didn't separate terms index from BKD index concepts -- both are "indexed=true". If we were to add a single field type that did both, we'd need to resolve that conundrum. We could also _not_ resolve that conundrum, and add nicer primitive-like terms index alternatives instead of forcing the user to use StrField.
On Mon, Sep 29, 2025 at 11:09 AM Jason Gerlowski <[email protected]> wrote: > At least originally we decided to keep Trie fields around because they > were faster for certain types of searches. I think Tries were faster > for range queries, but Points excelled at single-value lookups? > > Did we (or Lucene) ever address that in some way? Are Tries still > better for certain types of queries? That seems like an important > question to answer before any discussion of moving or removing them... > > Best, > > Jason > > On Sat, Sep 27, 2025 at 7:31 AM David Eric Pugh <[email protected]> > wrote: > > > > Hoss, I had a conversation with David (on the phone) about just that > idea, of moving some things to solr-sandbox, so I am definitely receptive > to it. > > TrieField is a good example of one who is maybe okay just "hiding" in > the source tree. > > One issue with moving it to sandbox is that we don't really have > releases from there, correct? I think for me, the effort is "Does > spinning up the tooling to release Trie as a module" overwhelm the "Hey, > fewer workarounds". At least for me, it's not on my immediate "hit list" > for removal to Solr 10. But the moment it holds anything up specific... > Then that calculus changes for me. Now, if I can just move them to > solr-sandbox and not provide any release tooling around, that makes it more > attractive. Not sure how much of a issue that would be to current users > like Rahul however... > > Also, we really just need to fix the underlying reason you like > TrieFields, which is the updating issue! > > On Friday, September 26, 2025 at 07:11:19 PM EDT, Chris Hostetter < > [email protected]> wrote: > > > > > > : I'd prefer to see Trie fields hang out a bit longer. These fields are > > : proper plugins (i.e. they subclass types), so their presence is > relatively > > : minor for their project maintenance impact. > > > > Hrm, sort of? > > > > 1) There is a lot cruft sprinkled through out the codebase for dealing > > with TrieFields -- most of it is in faceting, but there is also weird > > little hacks like a workaround for SOLR-9809 in DocumentBuilder > > > > hossman@slate:~/lucene/solr [j21] [main] $ find -name \*.java | grep -v > test | grep -v '/schema/' | xargs grep -E > 'TrieField|Trie(Date|Double|Float|Int|Long)Field' | wc -l > > 42 > > > > > > 2) We currently randomize the use of Trie numeric fields in 20% of our > > test runs -- which means means 20% less testing of fields we actually > want > > people to use. > > > > > > 3) Because of #2, any time someone tries to add new code and runs into a > > werid quirk with Trie fields, it either has to be fixed, or hacked around > > (see #1) > > > > > > At some point, we have to accept that it's time to pull a Marie Kondo, > > thank the Trie fields, and send them on their way. > > > > > > > > -Hoss > > http://www.lucidworks.com/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
