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
= 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
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
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
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:
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
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