: Higher level optimizations that do query transformations are left as
: an exercise to the application :-)
Word!
For example, Yonik helped me speed up a fairly hairy query i had a while
back by realizing that the way i was progromatically generating a query,
one deeply nested clause was actuall
.org
Sent: Friday, June 9, 2006 3:08:35 PM
Subject: RE: Different scoring mechanism
: For example: a query containing two terms: "fast", "car", having
: document frequencies 300.000 and 20.000 in the index respectively. In a
: worst case scenario this would require 320.000 doc
From: Chris Hostetter <[EMAIL PROTECTED]>
To: java-user@lucene.apache.org
Sent: Friday, June 9, 2006 3:08:35 PM
Subject: RE: Different scoring mechanism
: For example: a query containing two terms: "fast", "car", having
: document frequencies 300.000 and 20.000 in th
: For example: a query containing two terms: "fast", "car", having
: document frequencies 300.000 and 20.000 in the index respectively. In a
: worst case scenario this would require 320.000 document scores to be
: calculated. I am not really sure how lucene optimizes its search, but I
: guess it
> :! If a document does not contain a queryterm this score
> can be larger
> : or smaller than 0 !
>
> if a document doesn't contain a term, then the scorer for
> that query will never even try to score that document --
> regardless of what your Similarity class looks like.
>
> if you real
:! If a document does not contain a queryterm this score can be larger
: or smaller than 0 !
if a document doesn't contain a term, then the scorer for that query will
never even try to score that document -- regardless of what your
Similarity class looks like.
if you really want this kind of
Hi,
I am trying to implement an alternative scoring mechanism in Lucene.
A query of multiple terms is represented as a BooleanQuery with one or more
Occur.SHOULD clauses.
The scoring for a document is very simple:
- Assign a score for each queryterm.
! If a document does not contain a queryt