On Wed, Jan 18, 2017 at 6:07 AM, Adrien Grand wrote:
>
> We are open to feedback, what issues are you having with
> ConstantScoreWeight? It is true that it does not bring much compared to
> Weight anymore now that we removed query normalization. The only useful
> thing it has is the default explai
Hi,
I am using Lucene4.4. I am using the SimpleFacetsExample that is in the
demo. DrillDownQuery works fine when I have only one filter. But, then I
tried to add another filter:
My code:
q.add(new CategoryPath("Date/2010", '/'));
q.add(new CategoryPath("Date/2012", '/'));
I got this err
Hi,
For display you generally would only calculate it for a few documents and not
all. So why do you think it's a problem?
You cannot store values somewhere in the scorer for use during document
retrieval.
Uwe
Am 17. Januar 2017 20:40:32 MEZ schrieb sidhant92 :
>Okay say i need the distance f
Okay say i need the distance for filtering purposes. And then again i need
the distance for scoring purposes. I also need the distance for display
purposes and i display some 100 results. So are you sayings its still okay
to compute the distance twice here once for scoring and once for display
rath
Le jeu. 12 janv. 2017 à 00:31, Trejkaz a écrit :
> In the future now, looking at Lucene 6.3 Javadocs, where Filter is now
> gone, and it seems that ConstantScoreWeight is still @lucene.internal
> (and awfully hard to understand how it can do much at all...). Did we
> ever get a replacement class
I think the reason why there was no deprecation notice is that this code
was considered as internal code rather than something that we explicitly
expose to users as an API.
Le jeu. 12 janv. 2017 à 22:30, Chris Hostetter a
écrit :
>
> I don't konw the rhyme/reason but it looks like it was removed
Sorry I just saw your other message that has a bit more information.
Actually you do not need the distance for displaying purposes but both for
filtering and custom scoring. That said, I think recomputing the distances
is still the way to go. Geo-distance filters have optimizations that allow
them
Maybe recomputing the distance is not too bad? Say you have millions of
documents and only ask for the top 100, then recomputing distances for that
top 100 would be much cheaper than what you already had to do to compute
the scores.
Le ven. 13 janv. 2017 à 18:08, sidhant92 a écrit :
> I am using
In your 2nd test, the number of hits was still 25K, even though you
added another 1M docs to the "general" data set? If not, then the
query needed to do more work and will run slower.
If so, the query still does need to do more work in order to skip over
the "gold" documents: that skipping (the a
Can you open an issue and post a test case showing how you tried to re-use?
E.g. you should be able to change the String[] path on the FacetField
instance, re-build the document with FacetsConfig.build, and it should
have worked, I believe.
Mike McCandless
http://blog.mikemccandless.com
On Tue
Another Update:
I am also observing that in BlockGroupongCollector if i sort by INDEX_ORDER and
make needs score true then my scorer is called once and i am still getting each
doc score. But when i change the Sort to RELEVANCE the scorer is called twice.
On Jan 16, 2017, at 12:18 PM, Sidhant A
Hi
We have modified our search query around most restrictive dataset, and as
expected the search performance increases.
BUT, if we increase the total data volume our search performance decreases,
despite of same query and restrictive dataset.
Example:
Total Dataset: 3 Million 25K
12 matches
Mail list logo
