Ya...I think i will store it in the database so that later it could be used in scoring/ranking for retrieval...:) Another thing i would like to see is whether the precision or recall will be much affaected by this... Regards, Maureen
Xiaocheng Luan <[EMAIL PROTECTED]> wrote:One side-effect of turning off the norms may be that the scoring/ranking will be different? Do you need to search by each of these many fields? If not, you probably don't have to index these fields (but store them for retrieval?). Just a thought. Xiaocheng Michael McCandless wrote: "maureen tanuwidjaja" wrote: > "The only simple workaround I can think of is to set maxMergeDocs to > keep all segments "small". But then you may have too many segments > with time. Either that or find a way to reduce the number of unique > fields that you actually need to store." > It is not possible for me to reduce the number of fields needed to > store... > > Could you recommend what is the maxMerge value that is small enough to > keep all segment small? > > I also would like to ask wheter, if optimize is successful,will it then > perform faster searching significantly compared to the unoptimized > one? I think you'd need to test different values for your situation. Maybe try 66,000 which will give you ~ 10 segments at your current number of docs? > I have the searching result in 30 to 3 minutes, which is actually quite > unacceptable for the "search engine" I build...Is there any > recommendation on how faster searching could be done? I think you'll need to turn off norms. I expect alot of the slowness is in loading the large norms files for the first time. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------- Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. --------------------------------- Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
