Re: Terms.regex performance issue

2011-09-15 Thread O. Klein
Read http://lucene.472066.n3.nabble.com/suggester-issues-td3262718.html http://lucene.472066.n3.nabble.com/suggester-issues-td3262718.html for more info about the QueryConverter. IMO Suggester should make it easier to choose between QueryConverters. As for the infix, WIKI says its planned featur

Re: Terms.regex performance issue

2011-09-15 Thread tbarbugli
Hi, I do have the same problem, i am looking for infix autocomplete, could you elaborate a bit on your QueryConverter - Suggester solution ? Thank You! -- View this message in context: http://lucene.472066.n3.nabble.com/Terms-regex-performance-issue-tp3268994p3338273.html Sent from the Solr - Use

Re: Terms.regex performance issue

2011-08-22 Thread Bill Bell
We do something like: http://localhost:8983/solr/provs/terms?terms.fl=payor&terms.regex.flag=case _insensitive&terms.regex=%28.*%29WHAT USER TYPES%28.*%29&terms.limit=-1 We want not just prefix but anywhere in the terms. On 8/19/11 5:21 PM, "Chris Hostetter" wrote: > >: Subject: Terms.regex

Re: Terms.regex performance issue

2011-08-21 Thread O. Klein
I see now in Suggester Wiki; Support for infix-suggestions is planned for FSTLookup (which would be the only structure to support these). -- View this message in context: http://lucene.472066.n3.nabble.com/Terms-regex-performance-issue-tp3268994p3273711.html Sent from the Solr - User mailing lis

Re: Terms.regex performance issue

2011-08-21 Thread O. Klein
Of course. Thats why I compared prefix to bla* and saw it was already a lot slower. -- View this message in context: http://lucene.472066.n3.nabble.com/Terms-regex-performance-issue-tp3268994p3273370.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: Terms.regex performance issue

2011-08-21 Thread Erick Erickson
Ah, in that case, comparing prefix and regex is an apples-to-oranges comparison. I expect regex to be slower, but a fairer comparison would be prefix to stuff* (which may be changed into a prefix enumeration for all I know). But comparing infix to prefix doesn't tell you much really Best Erick

Re: Terms.regex performance issue

2011-08-21 Thread O. Klein
Yeah, I was searching infix. It worked very nice for autocomplete. Made a custom QueryConverter for the Suggester so it gives proper suggestions for shingles. Will stick with that for now. Thanx for the feedback. -- View this message in context: http://lucene.472066.n3.nabble.com/Terms-regex-pe

Re: Terms.regex performance issue

2011-08-21 Thread Erick Erickson
Wait. Sometimes I get confused because gmail will substitute * for bolding, so in my client it looks like you're searching infix (e.g. leading and trailing wildcards). If that's the case, then your performance will always be poor, it has to enumerate all the terms in the field... If it's just bold

Re: Terms.regex performance issue

2011-08-19 Thread O. Klein
Terms.prefix was just to compare performance. The use case was terms.regex=.*query.* And as Markus pointed out, this will prolly remain a bottleneck. I looked at the Suggester. But like many others I have been struggling to make it useful. It needs a custom queryConverter to give proper suggestio

Re: Terms.regex performance issue

2011-08-19 Thread Chris Hostetter
: Subject: Terms.regex performance issue : : As I want to use it in an Autocomplete it has to be fast. Terms.prefix gets : results in around 100 milliseconds, while terms.regex is 10 to 20 times : slower. can you elaborate on how you are using terms.regex? what does your regex look like? .. pa

Re: Terms.regex performance issue

2011-08-19 Thread Markus Jelsma
TermsComponent uses java.util.regex which is not particulary fast. If the number of terms grows your CPU is going to overheat. I'd prefer an analyzer approach. > As I want to use it in an Autocomplete it has to be fast. Terms.prefix gets > results in around 100 milliseconds, while terms.regex is