On Fri, Sep 12, 2014 at 2:58 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Fri, Sep 12, 2014 at 11:38 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Based on discussion thus far it seems that there's a possibility that
>> the trade-off may be different for short strings vs. long strings. If
>> the string is small enough to fit in the L1 CPU cache, then it may be
>> that memcmp() followed by strcoll() is not much more expensive than
>> strcoll(). That should be easy to figure out: write a standalone C
>> program that creates a bunch of arbitrary, fairly-short strings, say
>> 32 bytes, in a big array.
>
> While I think that's fair, the reason I didn't bother playing tricks
> with only doing a (purely) opportunistic memcmp() when the string size
> is under (say) CACHE_LINE_SIZE bytes is that in order for it to matter
> you'd have to have a use case where the first CACHE_LINE_SIZE of bytes
> matched, and the string just happened to be identical in length, but
> also ultimately differed at least a good fraction of the time. That
> seems like the kind of thing that it's okay to care less about. That
> might have been regressed worse than what you've seen already. It's
> narrow in a whole new dimension, though. The intersection of that
> issue, and the issues exercised by Heikki's existing test case must be
> exceedingly rare.
>
> I'm still confused about whether or not we're talking at cross
> purposes here, Robert. Are you happy to consider this as a separate
> and additional question to the question of what to do in an
> abbreviated comparison tie-break?
I think I've said a few times now that I really want to get this
additional data before forming an opinion. As a certain Mr. Doyle
writes, "It is a capital mistake to theorize before one has data.
Insensibly one begins to twist facts to suit theories, instead of
theories to suit facts." I can't say it any better than that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company