Thanks, you answered the main question - 26 doesn't simply lop off the time
of day. Although, I still don't completely follow how trie works (without
reading the paper itself.)
-- Jack Krupansky
-Original Message-
From: Uwe Schindler
Sent: Friday, December 14, 2012 5:58 PM
To: java-u
Hi,
> If I specify a precisionStep of 26 for a TrieDate field, what rough impact
> should this have on both performance and index size?
This value is mostly useless, everything > 8 does slowdown the queries tot he
speed of TermRangeQuery.
> The input data has time in it, but the milliseconds pe
If I specify a precisionStep of 26 for a TrieDate field, what rough impact
should this have on both performance and index size?
The input data has time in it, but the milliseconds per day is not needed for
the app. Will Lucene store only the top 64 minus 26 bits of data and discard
the low 26 b
Not that I know of. The easiest way to functionally group across
multiple fields is to concatenate multiple field values into
a special group field. This isn't a flexible solution, but it doesn't
require modifying the Lucene code.
The other solution you can try is to group by ValueSource (is like
I've also just found
http://stackoverflow.com/questions/11319465/geoclusters-in-solr where David
Smiley suggests using one field to store the levels (with a prefix) rather
than different fields.
N
--
View this message in context:
http://lucene.472066.n3.nabble.com/Using-GeohashPrefixTree-for-m
Wow, that's exactly what I'm talking about, and a very cool demonstration.
Unfortunately the mapping in my system is part of a faceted browsing over
the Solr/Lucene data set and so I cannot see your propriety web-based system
working for me, as I would need to connect to my indexes. However via yo
