I switched over to using FastVectorHighlighting, and the problem with
maxBooleanClause is resolved. I guess this is at the expense of having
a larger index (since you have to enable termVectors, termPositions and
termOffsets), but at least it's working.
Thanks for the help.
Mike
On Tue 03 Ja
: About bumping MaxBooleanQueries. You can certainly
: bump it up, but it's a legitimate question whether the
: user is well served by allowing that pattern as opposed
: to requiring 2 or 3 leading characters. The assumption
i think the root of the issue here is that when executing queries, reall
About bumping MaxBooleanQueries. You can certainly
bump it up, but it's a legitimate question whether the
user is well served by allowing that pattern as opposed
to requiring 2 or 3 leading characters. The assumption
behind the maxBooleanClause restriction is that
when there get to be that many cla
On 01/01/2012 07:48 AM, Erick Erickson wrote:
This may be the impetus for Hoss creating SOLR-2996.
Yep, it is indeed, though I believe this problem can also happen when a
user searches for something like q=a* in a big index. I need a bigger
index to know for sure about that, but from what I've
This may be the impetus for Hoss creating SOLR-2996.
I suspect this will go away if you use the correct
match-all-docs syntax, i.e. q=*:* rather than q=*
Hoss' suggestion in 2996 is to "do the right thing" with
q=*, but for now you need to use the right syntax.
But I'm not sure what highlighting
This question has come up a few times, but I've yet to see a good solution.
Basically, if I have highlighting turned on and do a query for q=*, I
get an error that maxBooleanClauses has been exceeded. Granted, this is
a silly query, but a user might do something similar. My expectation is
that
