On 21 June 2012 10:24, Florian Pflug <fgp@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