On Tue, Aug 2, 2016 at 1:56 PM, Alvaro Herrera <alvhe...@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

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:

Reply via email to