lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uwe Schindler <>
Subject Re: Quest about Lucene's query, int n) API's parameter n
Date Fri, 10 Jan 2020 06:55:19 GMT
You can sort with custom formulas. All values that are needed for calculation must be part
of the index as docvalues fields. You can then use expressions module to supply a formula
for the calculation, which may include the original score. The expressions module can override
the score (so standard sorting works) or provide a SortField.

It is only a bad idea to do this if the calculation is expensive, as it needs to be done for
every possible hit. One optimization is therefore to do a simple calculation using expressions,
which brings all documents into a average order, so only manually sorting top-n is ok.


Am January 10, 2020 4:39:58 AM UTC schrieb "小鱼儿" <>:
>I'm doing a POI(Point-of-interest) search using lucene, each POI has a
>"location" which is a GeoPoint/LonLat type. I need do a keyword-range
>search but the query result POIs need to sort by distance to a starting
>This "distance", in fact, is a dynamic computed property which cannot
>used by the SortField API, i doubt if Lucene can support a
>"DynamicSortField", that would be perfect. Or i had to do:
>use query, int n) API to first filter out
>POIs and then do a manual sort after these n documents' StoredField's
>all be loaded, which seems not efficient.
>The problem is, the parameter n in API has a
>problem, it may be not large enough to cover all the candidates. & the
>low-level search(Query, Collector) API seems to be short of
>If set the n to a very large value, the later sort proc may be very
>My current idea: use more detailed near-to-far sub geo ranges to
>iteratively/incrementally search/filter -> load documents -> manual
>sort ->
>Any suggestions?

Uwe Schindler
Achterdiek 19, 28357 Bremen
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message