Re: B-Tree support function number 3 (strxfrm() optimization)
От | Peter Geoghegan |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | CAM3SWZQ2xazBo8YdMKVhY1DgqyL0ynvYbfs6zD=QMkxWH_YDFg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas <robertmhaas@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
В списке pgsql-hackers по дате отправления: