On 1/7/17 10:01 PM, Peter Geoghegan wrote: > It occurs to me that the comparison caching stuff added by commit > 0e57b4d8b needs to be considered here, too. When we had to copy the > string to a temp buffer anyway, in order to add the terminating NUL > byte expected by strcoll(), there was an opportunity to do caching of > comparisons at little additional cost. However, since ICU offers an > interface that you're using that doesn't require any NUL byte, there > is a new trade-off to be considered -- swallow the cost of copying > into our own temp buffer solely for the benefit of comparison caching, > or don't do comparison caching. (Note that glibc had a similar > comparison caching optimization itself at one point, built right into > strcoll(), but it was subsequently disabled.)
That might be worth looking into, but it seems a bit daunting to construct a benchmark specifically for this, unless we have the one that was originally used lying around somewhere. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
