On Tue, Aug 2, 2016 at 1:56 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>> > How desirable is this feature? To begin answering that question,
>> > I did some initial benchmarking with an English text corpus to find how much
>> > faster BMH (Boyer-Moore-Horspool) would be compared to LIKE, and the results
>> > were as follows: BMH can be up to 20% faster than LIKE, but for short
>> > substrings, it's roughly comparable or slower.
>> >
>> > Here are the results visualized:
>> >
>> > http://ctrl-c.club/~ksikka/pg/like-strpos-short-1469975400.png
>> > http://ctrl-c.club/~ksikka/pg/like-strpos-long-1469975400.png
>>
>> Based on these results, this looks to me like a pretty unexciting
>> thing upon which to spend time.
>
> Uh, a 20% different is "unexciting" for you? I think it's interesting.
> Now, really, users shouldn't be running LIKE on constant strings all the
> time but rather use some sort of indexed search, but once in a while
> there is a need to run some custom query and you need to LIKE-scan a
> large portion of a table. For those cases an algorithm that performs
> 20% better is surely welcome.
Sure, but an algorithm that performs 20% faster in the best case and
worse in some other cases is not the same thing as a 20%
across-the-board performance improvement. I guess if we had a way of
deciding which algorithm to use in particular cases it might make
sense.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
