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)
Re: levenshtein_less_equal (was: multibyte charater set in levenshtein function) |
Список | 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 по дате отправления: