: is if the query starts with a wildcard. In the case where it starts with a
: wildcard, lucene has no option but to linearly go over every term in the
: index to see if it matches your pattern. It must visit every singe term in
That would explain why the search itself takes a while, but not why
accessing the hits after the call to search would take a while. note
where the timing code is in his example.
There are two possible explanations i can think of...
: >>It seems when I have a wilcard query like *abcd* vs weqrew*, the *abcd*
: query will always take longer to retrieve the documents even if they are of
: simular result sizes. We are talking a big difference 1 second vs 16. It is
1) How similar, and how many? ... If i remember correctly, the Hits
constructor does some work to pre-fetch the first 100 results. So if you
are iterating over all of the results, the first 100 are free. On the
101st iteration the prefetching method is called again to fetch N more (i
don't remember what N is off the top of my head.
what this means is that if you are only timing the method calls on Hits,
then the first 100 documents are free -- if one wildcard search returns 99
results, and the other returns 105 results, those numbers may not seemthat
different, but in the first case the code you are timing is accessing
nothing but memory, and in the second case it has to read from disk.
2) The second idea also requires you to answer a question" the number of
results returned for each query might be identicle, but are the
results themselves identical?
I'm guessing that either the documents from the "slow" case are either
much bigger (ie: larger stored fields) or the results from the fast case
are all documents that are "near" eachother on disk, so fetching back all
of hte stored fields would require less IO then if the results are stored
farther apart. If i remember correctly, the stored fields of documents
are kept in order that the documents are added, so hypothetically, the
query you did was on a "name" field, and the documents were added to the
index in alphabetical order by "name" then by definition the results for
"weqrew*' will all be close together, while the results for "*abcd*" will
be spread out throughout the index.
an easy way to disprove that 2nd theory would be to change your timing
code to this and see what happens...
Hits hits = searcher.search(query);
long startTime = System.currentTimeMillis();
for (int i = 0; i < hits.length(); i++) {
int id = hits.id(i);
}
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
