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

On Mon, Sep 15, 2014 at 1:34 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Mon, Sep 15, 2014 at 10:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> It strikes me that perhaps we should make this change (rearranging
>> things so that the memcmp tiebreak is run before strcoll) first,
>> before dealing with the rest of the abbreviated keys infrastructure.
>> It appears to be a separate improvement which is worthwhile
>> independently of what we do about that patch.
>
> I guess we could do that, but AFAICT the only open item blocking the
> commit of a basic version of abbreviated keys (the informally agreed
> to basic version lacking support for single-attribute aggregates) is
> what to do about the current need to create a separate sortsupport
> state. I've talked about my thoughts on that question in detail now
> [1].

I think there's probably more than that to work out, but in any case
there's no harm in getting a simple optimization done first before
moving on to a complicated one.

> BTW, you probably realize this, but we still need a second memcmp()
> after strcoll() too. hu_HU will care about that [2].
>
> [1] http://www.postgresql.org/message-id/CAM3SWZQCDCnfWd3qzoO4QmY4G8oKHUqyrd26bBLa7FL2x-nTjg@mail.gmail.com
> [2] http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=656beff59033ccc5261a615802e1a85da68e8fad

I rather assume we could reuse the results of the first memcmp()
instead of doing it again.

x = memcmp();
if (x == 0)  return x;
y = strcoll();
if (y == 0)  return x;
return y;

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company