On Wed, Oct 13, 2010 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?
levenshtein_less_equal(a, b, max_d) returns the same value as
levenshtein(a, b) if levenshtein(a, b) <= max_d. Otherwise it returns
max_d + 1. So it's the same test case with a small distance bound (2)
applied. As Alexander says, the value of levenshtein_less_equal
accelerates pretty rapidly when long strings are involved, so it seems
worth having, but I'm not sure I agree that the slowdown to the basic
function is negligible. It is not really all that much #ifdef hackery
to avoid it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company