On Mon, Apr 7, 2014 at 10:47 AM, Robert Haas <robertmh...@gmail.com> wrote: > To throw out one more point that I think is problematic, Peter's > original email on this thread gives a bunch of examples of strxfrm() > normalization that all different in the first few bytes - but so do > the underlying strings. I *think* (but don't have time to check right > now) that on my MacOS X box, strxfrm() spits out 3 bytes of header > junk and then 8 bytes per character in the input string - so comparing > the first 8 bytes of the strxfrm()'d representation would amount to > comparing part of the first byte. If for any reason the first byte is > the same (or similar enough) on many of the input strings, then this > will probably work out to be slower rather than faster. Even if other > platforms are more space-efficient (and I think at least some of them > are), I think it's unlikely that this optimization will ever pay off > for strings that don't differ in the first 8 bytes.
Why would any platform have header bytes in the resulting binary strings? That doesn't make any sense. Are you sure you aren't thinking of the homogeneous trailing bytes that you can also see in my example? The only case that this patch could possibly regress is where there are strings that differ beyond about the first 8 bytes, but are not identical (we chance a memcmp() == 0 before doing a full strcoll() when tie-breaking on the semi-reliable initial comparison). We still always avoid fmgr-overhead (and shim overhead, which I've measured), as in your original patch - you put that at adding 7% at the time, which is likely to make up for otherwise-regressed cases. There is nothing at all contrived about my test-case. You have to have an awfully large number of significantly similar but not identical strings in order to possibly lose out. Even if you have such a case, and the fmgr-trampoline-elision doesn't make up for it (doesn't make up for having to do a separate heapattr lookup on the minimal tuple, and optimization not too relevant for pass by reference types), which is quite a stretch, it seems likely that you have other cases that do benefit, which in aggregate makes up for it. The benefits I've shown, on the first test case I picked are absolutely enormous. Now, let's assume that I'm wrong about all this, and that in fact there is a plausible case where all of those tricks don't work out, and someone has a complaint about a regression. What are we going to do about that? Not accelerate text sorting by at least a factor of 3 for the benefit of some very narrow use-case? That's the only measure I can see that you could take to not regress that case. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
