On 21 June 2012 10:24, Florian Pflug <f...@phlo.org> wrote: > On Jun21, 2012, at 02:22 , Peter Geoghegan wrote: >> I've written a very small C++ program, which I've attached, that >> basically proves that this can still make a fairly large difference - >> I hope it's okay that that it's C++, but that allowed me to write the >> program quickly, with no dependencies for anyone who cares to try this >> out, other than a C++ compiler and the standard library. > > Uh, are you sure the results aren't swapped? string_wrapper takes a > parameter called use_strcoll, and it indeed uses strcoll() if that > parameter is true, and strxfm() otherwise. But then it passes *false* > to determine the speed of strcoll(), and *true* to determine the speed > of strxfm()...
Egads, you're right. Apparently in my haste I gave the wrong boolean argument to the class constructor in each case. I am completely wrong about this. I apologise for the careless mistake. At least I advanced the debate, though - we don't want to do any ad-hoc generation of strxfrm() output within comparators, even when one side can have a cached value. You're right about merge-joins; I cannot answer that without arbitrarily making a convenient exception about the conditions that they join on, which is itself unacceptable. I cannot change the semantics of equality to do something with strxfrm either, since that would have unacceptable performance implications, as is evident from my test-case. I wish someone had a better idea, but I suppose at this point the idea of concatenating strxfrm() output with the original string begins to look like the least-worst option. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
