Re: field:* query type, and prefix queries

[Chris Hostetter <ho...@fucit.org>]

: Just out of interest, why does field:* go via getWildcardQuery instead of 
: getPrefixQuery?  It seems to me that it should be treated as a prefix of "", 
: but am I missing something important?

i think it's just an artifact of the grammer ... the first character of 
"the string" is a wildcard character, therefore it's a wildcard query.

: Also, I've noticed that although RangeQuery was optimised in a recent version 
: of Lucene, PrefixQuery is still quite slow even though any prefix query and 
: range query both walk through a list of adjacent terms.  I would expect them 
: to take about the same amount of time to run if covering the same terms.

"optomized" is not a self contained concept you optimize for some 
measurement ... ConstantScoreRangeQuery was "optomized for memorey" in 
that a RangeQuery can balloon up into a large number of TermQueries and 
ConstantScoreRangeQuery can't, the trade off being that it scores each 
match with a constnat score (whereas RangeQuery scored each match relative 
to the idf of the term that matches).  the default 
in QueryParser was changed to ConstantScoreRangeQuery because people 
typically don't expect "range queries" to matter which "term" in the range 
matches (i would guess 90% of the time people are using range queries for 
something numeric)

with a "prefix query" on the other hand, having the idf influence the 
score does still frequently make sense -- so there hasn't been as much of 
a push to change the QueryParser to use a "ConstantScoringPrefixQuery" ... 
but it is still easy to do yourself: just make a ConstantScoreQuery 
arround the PrefixFilter.  (ConstantScoreRangeQuery is just a 
ConstantScoreQuery wrapped arround a RangeFilter)

-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org