finalize()-methods of FSDirectory.FSIndexInput and FSDirectory.FSIndexOutput
try to close already closed file
-
Key: LUCENE-669
URL: http://issues.apache.o
The same effect showed-up on athlon CPU... The only diference between your
PerfTest and what I have been doing is that your loop is as tight as it goes.
*Maybe* worth of investigating a bit futher as my tests look a bit closer to
the real usage scenarios.
I will try to identify cases where Ope
As suspected in my first email on this topic, test is wrong, garbage collection
was kicking in at wrong times so the results were convoluted. Ah, old good
predictable c times are long gone.
Anyhow, appologies for this noise (particulary to Yonik). The real speed
relationships are attached now,
On Thursday 07 September 2006 10:03, eks dev wrote:
...
>
> on the other note,
> the key for really efficiant matchers will be good SmartMatcherFactory that
picks the best representation for given density/"sortednes".
> The cases I've been able to identify so far:
>
> Very Low density - IntList
Robert Engels,
I implemented the reopen code you posted, works well, thanks. One thing I am
curious about, are you able to reuse the FieldCache? From what I am seeing, it
is being rebuilt after a commit, which makes the next query slow. Any ideas on
this?
Thanks,
Jason
"What's the point of using a sorted interval list for a category?"
Just terminology first to avoid misunderstanding :), category is "category
field" that can take N valus
Now, the case I am facing goes as follows:
I have category field in 50Mio collection which has more or less uniform
distri
improper isolation (overuse of system properties) allows Lucene apps to clobber
each other
--
Key: LUCENE-670
URL: http://issues.apache.org/jira/browse/LUCENE-670
