On Saturday 13 November 2004 09:16, Sanyi wrote:
> > - leave the current implementation, raising an exception;
> > - handle the exception and limit the boolean query to the first 1024
> > (or what ever the limit is) terms;
> > - select, between the possible terms, only the first 1024 (or what
> > e
> - leave the current implementation, raising an exception;
> - handle the exception and limit the boolean query to the first 1024
> (or what ever the limit is) terms;
> - select, between the possible terms, only the first 1024 (or what
> ever the limit is) more meaningful ones, leaving out all the
On Fri, 2004-11-12 at 14:52, Daniel Naber wrote:
> There are two different issues: first, reorder the query so that those
> terms with less matches appear first, because as soon as the first term
> with 0 matches occurs, search stops. There will probably be a
> non-so-difficult implementation f
On Friday 12 November 2004 21:28, Luke Francl wrote:
> > That's the point: there is no query optimizer in Lucene.
>
> Would it be possible to write one? I would be very interested in this
> feature.
There are two different issues: first, reorder the query so that those
terms with less matches ap
On Thu, 2004-11-11 at 14:48, Daniel Naber wrote:
> On Thursday 11 November 2004 20:57, Sanyi wrote:
>
> > What I'm saying is that there is no reason for the optimizer to expand
> > wild* to more than 1024 variations
>
> That's the point: there is no query optimizer in Lucene.
Would it be possibl
the following line:
> >
> > BooleanQuery.setMaxClauseCount( Integer.MAX_VALUE );
> >
> >
> > -Original Message-
> > From: Sanyi [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, November 11, 2004 6:46 AM
> > To: [EMAIL PROTECTED]
> > S
> It is normally possible to reduce the numbers of such complaints a lot
> by imposing a minimum prefix length
I've alread limited it to a minimum of 5 characters (abcde*).
I can still easily find (for the first try) situations where it starts to
search for minutes.
While another 5 char. partial
On Friday 12 November 2004 07:57, Sanyi wrote:
> > That's the point: there is no query optimizer in Lucene.
>
> Sorry, I'm not very much into Lucene's internal Classes, I'm just telling
your the viewpoint of a
> user. You know my users aren't technicians, so answers like yours won't make
them ha
> That's the point: there is no query optimizer in Lucene.
Sorry, I'm not very much into Lucene's internal Classes, I'm just telling your
the viewpoint of a
user. You know my users aren't technicians, so answers like yours won't make
them happy.
They will only see that I randomly don't allow the
On Thursday 11 November 2004 20:57, Sanyi wrote:
> What I'm saying is that there is no reason for the optimizer to expand
> wild* to more than 1024 variations
That's the point: there is no query optimizer in Lucene.
Regards
Daniel
--
http://www.danielnaber.de
-Original Message-
> From: Sanyi [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 11, 2004 6:46 AM
> To: [EMAIL PROTECTED]
> Subject: Bug in the BooleanQuery optimizer? ..TooManyClauses
>
>
> Hi!
>
> First of all, I've read about BooleanQuery$TooManyCl
1024 limit of clauses. I
automatically set it to max int with the following line:
BooleanQuery.setMaxClauseCount( Integer.MAX_VALUE );
-Original Message-
From: Sanyi [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 11, 2004 6:46 AM
To: [EMAIL PROTECTED]
Subject: Bug in the BooleanQuery
Hi!
First of all, I've read about BooleanQuery$TooManyClauses, so I know that it
has a 1024 Clauses
limit by default which is good enough for me, but I still think it works
strange.
Example:
I have an index with about 20Million documents.
Let's say that there is about 3000 variants in the entir
Hi!
First of all, I've read about BooleanQuery$TooManyClauses, so I know that it
has a 1024 Clauses
limit by default which is good enough for me, but I still think it works
strange.
Example:
I have an index with about 20Million documents.
Let's say that there is about 3000 variants in the entir
14 matches
Mail list logo
