An interesting thing

2006-06-11 Thread Flik Shen
directory. The time it consumed is 1348ms. How could this be? I think the time that buffered indexing consumes should base on the time of RAM indexing. I wonder why a buffered indexing even has a good performance than a ram indexing. So interesting!   Best regards, Flik Shen

RE: An interesting thing

2006-06-11 Thread Flik Shen
= Class FSversusRAMDirectoryTest End = -Original Message- From: yueyu lin [mailto:[EMAIL PROTECTED] Sent: Sunday, June 11, 2006 7:31 PM To: java-user@lucene.apache.org Subject: Re: An interesting thing In some OS, the ram is not only "RAM". The vi

RE: An interesting thing

2006-06-11 Thread Flik Shen
kinds of pages, OS has to first remove some using pages in memory and then load some pages from disk into ram. That's a great cost. For any program, applying huge memory is always slow than applying small memory. On 6/12/06, Flik Shen <[EMAIL PROTECTED]> wrote: > > One thing could

RE: IndexWriter.addIndexes & optimizatio

2006-06-11 Thread Flik Shen
It means that to pick both high maxBufferedDocs and mergeFator will improve your indexing performance. But if too high, it will lead you to an OutOfMemberException.exception. And if you set mergeFactor too high will also lead you to problem "open too many files". So you should pick proper values a

RE: An interesting thing

2006-06-11 Thread Flik Shen
e at first running than second time. This is why the buffered indexing runs faster when ram indexing prior to buffered . > -Original Message- > From: Flik Shen [mailto:[EMAIL PROTECTED] > Sent: Monday, June 12, 2006 11:29 AM > To: java-user@lucene.apache.org > Subject:

RE: Asserting that a value must match the entire content of a field

2006-06-12 Thread Flik Shen
I think you could follow Erik's advice. You could index you document's title as an un-tokenized field. Then searcher will treat the title as a whole string. If you hope when user inputs "Lifecycle", this document also be hit, you should think any other ways to solve your problem. > -Original

about PrefixQuery Matching

2006-06-13 Thread Flik Shen
When I study PrefixQuery, I found a problem. For example search string: test(*) This could match testX, testX...X, but not to match test only. Is it real problem? CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended s