Re: B-Tree support function number 3 (strxfrm() optimization) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id CAM3SWZSFdY9XKo_QOwdUHH5A-o_JpuVnb0xDoU6vAMi0u_djeQ@mail.gmail.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)
Re: B-Tree support function number 3 (strxfrm() optimization)
List pgsql-hackers
On Wed, Jan 21, 2015 at 4:44 AM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
> Now, I follow this general principle that someone who is not doing the
> work should never say "X is easy" to someone who _is_ doing it, unless
> they're prepared to at least outline the solution on request or
> otherwise contribute.  So see the attached patch (which I will concede
> could probably do with more comments, it's a quick hack intended for
> illustration) and tell me what you think is missing that would make it a
> complicated problem.

Okay, then. I concede the point: We should support the datum case as
you outline, since it is simpler than any alternative. It probably
won't even be necessary to formalize the idea that finished
abbreviated keys must be pass-by-value (at least not for the benefit
of this functionality); if someone writes an opclass that generates
pass-by-reference abbreviated keys (I think that might actually make
sense, although I'm being imaginative), it simply won't work for the
datum sort case, which is probably fine.

Are you going to submit this to the final commitfest? I'll review it if you do.
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: plpgsql - Assert statement
Next
From: Jim Nasby
Date:
Subject: Re: proposal: plpgsql - Assert statement