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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: levenshtein_less_equal (was: multibyte charater set in levenshtein function)
Дата
Msg-id 27008.1286984548@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: levenshtein_less_equal (was: multibyte charater set in levenshtein function)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: levenshtein_less_equal (was: multibyte charater set in levenshtein function)  (Robert Haas <robertmhaas@gmail.com>)
Re: levenshtein_less_equal (was: multibyte charater set in levenshtein function)  (Alexander Korotkov <aekorotkov@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Oct 13, 2010 at 10:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> But the main point is that 6% performance penalty in a non-core function
>> is well below my threshold of pain.

> Well, then you have to wonder whether it's worth having the
> lesss-than-or-equal-to version around at all.  That's only about 2x
> faster on the same test case.

"Same" test case?  I thought they did different things?

> I do think it's likely that people who
> call this function will call it many times, however - e.g. trying to
> find the closest matches from a dictionary for a given input string,
> so the worry about performance doesn't seem totally out of place.

No doubt, but the actual function runtime is only one component of the
cost of applying it to a lot of dictionary entries --- I would think
that the table read costs are the larger component anyway.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: SQL command to edit postgresql.conf, with comments
Следующее
От: Tom Lane
Дата:
Сообщение: Re: leaky views, yet again