The highlighters are the only thing I know of (in trunk) that do
something like that.
Work on this branch
(https://issues.apache.org/jira/browse/LUCENE/fixforversion/12317158) is
an attempt to make that more efficient.
In general the problem with doing this during scoring (the filtering
docid phase) is you don't know which documents will be returned because
they are being sorted by score (or something else), and only at the end
do you have the top N.
So there always tends to be an element of re-evaluating the query; it's
just a question of making that as optimal as possible.
-Mike
On 1/24/2014 12:31 PM, Olivier Binda wrote:
Hello
While searching a query, I guess that Lucene traverses a
Field->Term->DocId structure, filters the docIds that satisfy the
query, score them and then sort them
Given a resulting docId, I would like a way to find at least a valid
path (or the first valid path or all valid paths) that made this docId
pass the filtering phase
For example, if you consider that the query "A:a OR B:a OR C:a" is a
tree with the branch
A:a = 1
B:a = 2
C:a = 3
Some docId will get through 1
others through 2
and the others through 3
Is there a way to do that and what what would be the most efficient
way (time and memory wise) ?
I think that highlighting tries to solve quite the same problem (but
it seems quite heavy on the computationnal side).
My idea was : isn't it possible at the "Lucene filtering docId phase",
to save the path (an int, if you traverse the query like a tree) that
made the docId pass the query ? (which would make it cheap
computationnaly wise)
Best regards,
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
