lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira] [Commented] (LUCENE-2667) Fix FuzzyQuery's defaults, so its fast.
Date Sat, 10 Nov 2012 00:37:33 GMT
I'm -1 for having unscalable shit in lucene's core. This query should
have never been added.

I don't care if a few people complain because they aren't using
lowercasefilter or some other insanity. Fix your analysis chain. I
don't have any sympathy.

On Fri, Nov 9, 2012 at 7:35 PM, Jack Krupansky <jack@basetechnology.com> wrote:
> +1 for permitting a choice of fuzzy query implementation.
>
> I agree that we want a super-fast fuzzy query for simple variations, but I
> also agree that we should have the option to trade off speed for function.
>
> But I am also sympathetic to assuring that any core Lucene features be as
> performant as possible.
>
> Ultimately, if there was a single fuzzy query implementation that did
> everything for everybody all of the time, that would be the way to go, but
> if choices need to be made to satisfy competing goals, we should support
> going that route.
>
> -- Jack Krupansky
>
> From: Mark Bennett
> Sent: Friday, November 09, 2012 3:48 PM
> To: dev@lucene.apache.org
> Subject: Re: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira]
> [Commented] (LUCENE-2667) Fix FuzzyQuery's defaults, so its fast.
>
> Hi Robert,
>
> On Thu, Sep 13, 2012 at 7:39 PM, Robert Muir <rcmuir@gmail.com> wrote:
>>
>> ...
>> ... I'm strongly against having this
>> unscalable garbage in lucene's core.
>>
>> There is no use case for ed > 2, thats just crazy.
>
>
> I promise you there ARE use cases for edit distances > 2, especially with
> longer words.  Due to NDA I can't go into details.
>
> Also ed>2 can be useful when COMBINING that low-quality part of the search
> with other sub-queries, or additional business rules.  Maybe instead of
> boiling an ocean this lets you just boil the sea.  ;-)
>
> I won't comment on the quality of the older Levenstein code, or the likely
> very slow performance, nor where the code should live, etc.
>
> But your statement about "no use case for ed > 2" is simply not true.
> (whether you'd agree with any of them or not is certainly another matter)
>
> I understand your concerns about not having it be the default.  (or maybe
> having a giant warning message or something, whatever)
>
>> --
>> lucidworks.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message