Hi Erick, hi Adrien, thank you for both of your replies.
>> In a word, "no". When you set stored="true", Solr (well >> actually Lucene) puts a compressed verbatim copy on disk. I am using Lucene directly, not Solr, so I had the hope of being able to configure the "store behavior" at this lower level. (From the Javadoc it looks like SortedDocValuesField has this sharing behavior, but AFAIK DocValues are not retrievable as StoredFields are.) >> "Disk space is cheap" is the usual response here If we were talking a server application here, I would agree. But our application is a search plugin for the Eclipse IDE and for some reason developers are still surprisingly sensitive about their workspaces consuming a few hundred megabytes of disk space. > You can still give an id to each value on the application side if you want > to avoid repeating values. I am afraid I don't understand. Do you suggest using IntFields as ID instead of StringFields, as they are presumably stored more efficiently? > Otherwise, even without doing anything, things > should not be too bad thanks to stored fields compression. AFAICT, the fields are not compressed on disk right now. At least, "grep -c" finds my field over and over in the index files. So, how do I enabled stored fields compression. Googling turned up Store.COMPRESS, but that doesn't exist in 5.2.1. Best wishes, Andreas -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
