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

On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> That would have the
> nice property of avoiding the need for special handling in
> reversedirection_heap().

Oh, BTW, we probably don't need that anyway, since I'm already
disabling abbreviated key optimization in the event of a bounded sort
on the grounds that in general it doesn't pay for itself. So maybe
reversedirection_heap() (and perhaps other tuple-type variants of
same) should merely note: "If ever abbreviated keys with top-N heap
sort start to make sense, the logic to invert ordering would have to
be duplicated here". Technically, right now what I've added to
reversedirection_heap() is dead code. What do you think of that?

It's still not clear that the explicit "tie-breaker" comparator
introspection is paying for itself: as I've already pointed out, we
may well be better off always trying a memcmp() tie-breaker first, and
not bothering with the distinction between whether or not a given
comparison has been called as a tie-breaker, or whether there never
was an abbreviated comparison to have to tie-break in the first place.
Even if we're better off always being optimistic about a "try memcmp()
== 0" paying off for text, there are other datatypes, and it might be
a more useful distinction for those other datatypes. Which is not to
suggest that it's clear that it isn't a useful distinction to make in
the case of text.

--
Peter Geoghegan