Be a little careful when looking at the index files on disk, see: http://lucene.apache.org/java/3_5_0/fileformats.html#file-names
One issue is that you can pretty much ignore the *.fdt and *.fdx files when thinking about the amount of RAM you need. These files have to do with stored data and really don't have much impact on the pure *searching* part of the process and a minimal impact on the RAM requirements (there'll be a little bit of memory for the documentCache, but by and large not enough to matter). Best Erick On Mon, Jan 9, 2012 at 8:52 AM, jimmy <jimmyt...@bobmail.info> wrote: > Thanks for the fast reply. I went with your suggestion and saved the full > category path as well the category_id as integer. I also tested the index > space consumption and it was less than I thought. > > So, if i only store the category_id as an integer I have a full index size > of 246MB. > With the full category path (just indexed and not stored) it's 275MB. Only > 12% more. > If I also store the field, it goes up to 342MB, but I don't think this is > necessary. > > > Ted Dunning wrote >> >> Option 3 is preferably because you can use phrase queries to get >> interesting results as in "color light beige" or "color light". >> >> Normalizing is bad in this kind of environment. >> > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/complex-keywords-hierarchical-data-Solr-representation-problem-tp3642588p3644563.html > Sent from the Solr - User mailing list archive at Nabble.com.