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 sense. -- 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
