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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(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 15:42:28
Message-ID: 27008.1286984548@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Oct 13, 2010 at 10:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-10-13 15:45:51 Re: leaky views, yet again
Previous Message Kevin Grittner 2010-10-13 15:25:40 Re: leaky views, yet again