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

From Robert Haas
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id CA+TgmoZxsQzDJXJE-CgdGTSZO=7Xw_k2ukvemOdfcArbg2veVA@mail.gmail.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)
List pgsql-hackers
On Thu, Aug 7, 2014 at 3:15 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Aug 6, 2014 at 7:18 PM, Peter Geoghegan <pg@heroku.com> wrote:
>> On Wed, Aug 6, 2014 at 1:11 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> I've committed the patch I posted yesterday.  I did not see a good
>>> reason to meld that together in a single commit with the first of the
>>> patches you posted; I'll leave you to revise that patch to conform
>>> with this approach.
>>
>> Okay. Attached is the same patch set, rebased on top on your commit
>> with appropriate amendments.
>
> Two things:
>
> +        * result.  Also, since strxfrm()/strcoll() require
> NULL-terminated inputs,
>
> In my original patch, I wrote NUL, as in the NUL character.  You've
> changed it to NULL, but the original was correct.  NULL is a pointer
> value that is not relevant here; the character with value 0 is NUL.

Gah.  Hit send to soon.  Also, as much as I'd prefer to avoid
relitigating the absolutely stupid debate about how to expand the
buffers, this is no good:

+               tss->buflen1 = Max(len1 + 1, tss->buflen1 * 2);

If the first expansion is for a string >512MB and the second string is
longer than the first, this will exceed MaxAllocSize and error out.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Next
From: Tom Lane
Date:
Subject: Re: Fixed redundant i18n strings in json