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

On Tue, Dec 2, 2014 at 2:07 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Well, maybe you should make the updates we've agreed on and I can take
> another look at it.

Agreed.

> But I didn't think that I was proposing to change
> anything about the level at which the decision about whether to
> abbreviate or not was made; rather, I thought I was suggesting that we
> pass that flag down to the code that initializes the sortsupport
> object as an argument rather than through the sortsupport structure
> itself.

The flag I'm talking about concerns the *applicability* of
abbreviation, and not whether or not it will actually be used (maybe
the opclass lacks support, or decides not to for some platform
specific reason). Tuplesort has a contract with abbreviation +
sortsupport that considers whether or not the function pointer used to
abbreviate is set, which relates to whether or not abbreviation will
*actually* be used. Note that for non-abbreviation-applicable
attributes, btsortsupport_worker() never sets the function pointer
(nor, incidentally, does it set the other abbreviation related
function pointers in the struct).

--
Peter Geoghegan