That's great, just what I needed, I was debugging and was expecting to
see something like this.
i'll look through the SVN history to see in which version it was added.
Thanks
On Wednesday, March 2, 2011, Yonik Seeley wrote:
> On Wed, Mar 2, 2011 at 2:43 PM, Ofer Fort wrote:
>> I didn't see this
I didn't see this behavior, running solr 1.4.1, was that implemented
after this release?
On Wednesday, March 2, 2011, Yonik Seeley wrote:
> On Wed, Mar 2, 2011 at 1:58 PM, Ofer Fort wrote:
>> Thanks,
>> But each query tries to see if there is something new since the last result
>> that was found
I'm guessing what i was describing is a short-circuit evaluation and i see
that lucene doesn't have it:
http://lucene.472066.n3.nabble.com/Short-circuit-in-query-td738551.html
Still would love to hear any suggestions for my type of query
ofer
On Wed, Mar 2, 2011 at 8:58 PM, Ofer Fort wrote:
>
Thanks,
But each query tries to see if there is something new since the last result
that was found, so rounding things will return the same documents over and
over again, till we reach to the next rounded point.
Could i use the document id somehow? or something else that's bigger than
my last se
On Wed, Mar 2, 2011 at 2:43 PM, Ofer Fort wrote:
> I didn't see this behavior, running solr 1.4.1, was that implemented
> after this release?
I think so.
It's implemented now in BooleanWeight.scorer()
for (Weight w : weights) {
BooleanClause c = cIter.next();
Scorer subSc
On Wed, Mar 2, 2011 at 1:58 PM, Ofer Fort wrote:
> Thanks,
> But each query tries to see if there is something new since the last result
> that was found, so rounding things will return the same documents over and
> over again, till we reach to the next rounded point.
>
> Could i use the document
timestamp is of type:
On Wed, Mar 2, 2011 at 8:11 PM, Ofer Fort wrote:
> you are correct that my query is a tange one, probably should have
> mentioned it in the first post.
> this is the debug data:
>
>
>
>
>
> 0
> 4173
>
> on
> on
>
> 0
> timestamp:[2011-02-01T00:00:00Z TO NO
you are correct that my query is a tange one, probably should have mentioned
it in the first post.
this is the debug data:
0
4173
on
on
0
timestamp:[2011-02-01T00:00:00Z TO NOW] AND oferiko
2.2
10
timestamp:[2011-02-01T00:00:00Z TO NOW] AND
oferiko
timestamp:[2011-02-0
On Wed, Mar 2, 2011 at 12:11 PM, Ofer Fort wrote:
> Hey all,
> I have an index with a lot of documents with the term X and no documents
> with the term Y.
> If i query for X it take a few seconds and returns the results.
> If I query for Y it takes a millisecond and returns an empty set.
> If i qu
Thanks,
I tried it in the past and found out that my hit ratio was pretty low, so it
doesn't help most of my queries
ofer
On Wed, Mar 2, 2011 at 7:16 PM, Geert-Jan Brits wrote:
> If you often query X as part of several other queries (e.g: X | X AND Y |
> X AND Z)
> you might consider putting
If you often query X as part of several other queries (e.g: X | X AND Y |
X AND Z)
you might consider putting X in a filter query (
http://wiki.apache.org/solr/CommonQueryParameters#fq)
leading to:
q=*:*&fq=X
q=Y&fq=X
q=Z&fq=X
Filter queries are cached seperately which means that after the firs
Hey all,
I have an index with a lot of documents with the term X and no documents
with the term Y.
If i query for X it take a few seconds and returns the results.
If I query for Y it takes a millisecond and returns an empty set.
If i query for Y AND X it takes a few seconds and returns an empty set
12 matches
Mail list logo
