Yeah, I do the (*:* AND -type:foo) OR something:else
thing on my own pretty big index, and it's not slow at all. At least no
slower than doing any other "X OR Y" where X and Y both include lots of
results.
Pre-warming the field cache for, in this case, the 'type' field may
help. Same as it would if 'X' were just "type:bar" (not negated) where
"type:bar" matched about the same number or documents as "-type:foo"
does in your case. In general, there's nothing special that should make
that slow, it's a pretty ordinary query, really. Just using weird syntax
to get around lucene query parser issues.
[Obligatory mention: This may have nothing to do with your issue, but I
have found occasions where not having enough RAM allocated to Solr 1.4.1
can make things terribly slow, even though there is no OutOfMemory error
or other error in the logs. Especially if you are doing facetting and/or
StatsComponent. Excaserbated if you are using the default JVM GC
strategies instead of picking some of the concurrent strategies.]
On 4/25/2011 5:02 PM, Yonik Seeley wrote:
On Mon, Apr 25, 2011 at 4:49 PM, Simon Wistow<si...@thegestalt.org> wrote:
On Mon, Apr 25, 2011 at 04:34:05PM -0400, Jonathan Rochkind said:
This is what I do instead, to rewrite the query to mean the same thing but
not give the lucene query parser trouble:
fq=( (*:* AND -type:foo) OR restriction_id:1)
"*:*" means "everything", so (*:* AND -type:foo) means the same thing as
just "-type:foo", but can get around the lucene query parsers troubles.
So that might work for you.
Thanks for confirming my suspicions.
Unfortunately I've tried that as well and, whilst it works
it's also unbelievably slow (~30s query time).
It really shouldn't be that slow... how many documents are in your
index, and how many match -type:foo?
bq. Would writing my own Query Parser help here?
Nope. That's just syntax.
If filters of the form ( (*:* AND -type:foo) OR restriction_id:1)
are much slower (to the point where it causes you problems) and
filters of the form
type:foo) OR restriction_id:1
are fast, then you could index the negation of the type field as well
(if you know all the types)
For instance, in a doc, index two type fields:
type:bar
type_not:foo
Or if "type" is multi-valued, you could index both foo and NOT_foo in
the same field.
Then you could express the filter as type_not:foo OR restriction_id:1
or
type:NOT_foo OR restriction_id:1
-Yonik
http://www.lucenerevolution.org -- Lucene/Solr User Conference, May
25-26, San Francisco
