Re: levenshtein_less_equal (was: multibyte charater set in levenshtein function)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: levenshtein_less_equal (was: multibyte charater set in levenshtein function)
Date: 2010-10-13 14:51:59
Message-ID: 26040.1286981519@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of mi oct 13 10:32:36 -0300 2010:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> I spent some time hacking on this. It doesn't appear to be too easy
>>> to get levenshtein_less_equal() working without slowing down plain old
>>> levenshtein() by about 6%.
>>
>> Is that really enough slowdown to be worth contorting the code to avoid?
>> I've never heard of an application where the speed of this function was
>> the bottleneck.

> What if it's used on a expression index on a large table?

So? Expression indexes don't result in multiple evaluations of the
function. If anything, that context would probably be even less
sensitive to the function runtime than non-index use.

But the main point is that 6% performance penalty in a non-core function
is well below my threshold of pain. If it were important enough to care
about that kind of performance difference, it'd be in core. I'd rather
see us keeping the code simple, short, and maintainable.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-10-13 14:55:09 Re: Issues with two-server Synch Rep
Previous Message Alvaro Herrera 2010-10-13 14:36:02 Re: Extensions, this time with a patch