Re: B-Tree support function number 3 (strxfrm() optimization)

On Wed, Aug 6, 2014 at 1:11 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I've committed the patch I posted yesterday. I did not see a good
> reason to meld that together in a single commit with the first of the
> patches you posted; I'll leave you to revise that patch to conform
> with this approach.

Okay. Attached is the same patch set, rebased on top on your commit
with appropriate amendments.

BTW, I haven't added any of the same "portability" measures that the
existing strxfrm() selfuncs.c caller has. Since Windows can only use
the optimization with the C locale, I don't believe we're affected,
although the link
"http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=99694"
is now dead (even if you have a Microsoft account), so I won't swear
that Visual Studio 2005 is unaffected in the "C" locale case. However,
only VS 2008 and later versions support 64-bit builds, and only 64-bit
builds support abbreviated keys within sort support for text, so it
doesn't matter. As for the Solaris bugs that convert_string_datum()
also refers to, well, I just don't have much sympathy for that case.
If a version of Solaris that was old in 2003 still has a buggy
strxfrm() implementation and wants to use Postgres 9.5, too bad. My
usage of strxfrm() is the pattern that the standard expects. The idea
that we should always do a dry-run, where strxfrm() is called with a
NULL pointer to check how much memory is required, just because
somebody's strxfrm() is so badly written as to feel entitled to write
past the end of my buffer is just absurd. That should probably be
removed from the existing convert_string_datum() strxfrm() call site
too. I suspect that no Oracle-supported version of Solaris will be
affected, but if I'm wrong, that's what we have a buildfarm for.

The nodeAgg.c FIXME item remains. I've added a new TODO comment which
suggests that we investigate more opportunistic attempts at getting
away with a cheap memcmp() that indicates equality. That continues to
only actually occur when the sort support comparator is called as a
tie-breaker.

--
Peter Geoghegan