: Well, Doug provided this formula a few times, and I don't recall it off : the top of my head, but I do know that the .tii index file will be : fully read into memory, so look at the size of that file to get an : initial idea.
the other big piece of caching that goes on is the FieldCache which is used for sorting -- if you only ever sort by Score or doc ID, then it's a non-issue, but if your millions of Searchers are going to involve sorting on lots of different fields, the complete list of indexed values for each field used in sorting will be cached in memory per Searcher (close the Searcher, the WeakRef for the FieldCache is freed up) I can imagine some scenerios in which it might make sense to do all of the searches that sort on field A first, then close the searcher and open a new one and do all the searchers that sort on field B, then close the searcher, open a new one and do all the searches that sort on field C, etc.... : > I've got an application that performs millions of searches against a : > lucene index, can someone give me a bit of insight as to the memory : > consumption of these searches? Is there a cap on how many are kept : > around? is there any way I can disable caching for this type of : > search? : > : > -- : > ___________________________________________________ : > Chris Fraschetti : > e [EMAIL PROTECTED] : > : > --------------------------------------------------------------------- : > 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] : -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
