Well, it's just a long so unless you have a humongous number of documents in your shards, there are probably bigger fish to fry.
So I'd just try indexing with date math (e.g. /DAY) until I could demonstrate a problem. Best Erick On Sat, Dec 15, 2012 at 10:27 AM, Jack Krupansky <j...@basetechnology.com>wrote: > Maybe we're at the stage of raising the issue of whether the significant > extra storage for time of day warrants a storage format that is optimized > for day only, call it TrieDay (or TrieDateTimeless.) > > > -- Jack Krupansky > > -----Original Message----- From: jmlucjav > Sent: Saturday, December 15, 2012 6:04 AM > > To: solr-user@lucene.apache.org > Subject: Re: optimun precisionStep for DAY granularity in a TrieDateField > > without going through such rigorous testing, maybe for my case (interested > only in DAY), I could just index the trielong values such as 20121010, > 20110101 etc... > > This would take less space than trieDate (I guess), and I still have a date > looking number (for easier handling). I could even base the days on > 2000/01/01 and just index a single int (1..365, 366,...), but I don't think > it's worth for now, I prefer to keep an easier to understand number. > > thanks > > > > -- > View this message in context: http://lucene.472066.n3.** > nabble.com/optimun-**precisionStep-for-DAY-**granularity-in-a-** > TrieDateField-**tp4027078p4027193.html<http://lucene.472066.n3.nabble.com/optimun-precisionStep-for-DAY-granularity-in-a-TrieDateField-tp4027078p4027193.html> > Sent from the Solr - User mailing list archive at Nabble.com. >
