<<<Moved from pgsql-patches>>> Tom Lane wrote: > I wrote: > > I looked this over a bit and was immediately confused by one thing: > > the introductory comment says that the skip table size ought to be based > > on the length of the haystack, which makes sense to me, but the code is > > actually initializing it on the basis of len2, ie, the length of the > > needle. Isn't that a bug? Was the same bug present in the tests you > > made to determine the best table sizes? > > BTW, to the extent that you feel like testing a different idea, > I would suggest: > > * don't bother initializing the skiptable when len1 < len2 > > * otherwise, choose its size based on len1 - len2, not just len1 or > len2. This is (one less than) the maximum number of search loop > consultations of the skip table that can happen, so it seems like a > plausible number, and better than either length alone.
I've made the discussed changes. Also updated the benchmark results. http://www.unixbeast.com/~fat/8.3_test_v1.3.xls On re-benchmarking to determine the best skip table size, the changes to the logic didn't seem to affect the results enough to have to change the thresholds. But I'm sure it will perform a little better in cases like when both the needle and haystack are very long and close to being the same length. Having a big skip table in this case is a little bit of a waste as the search won't get to make much use of it.
boyer-moore-strpos_v1.3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
