On Wed, Oct 13, 2010 at 11:42 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Oct 13, 2010 at 10:51 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
