On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
