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+TgmoYbgGG-8WLD8J_2_AK22Pkx-QZeRMzKRvr3eWY5c8UctQ@mail.gmail.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)
List pgsql-hackers
On Thu, Aug 7, 2014 at 4:19 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Thu, Aug 7, 2014 at 12:17 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.
>
> Fair point. I think this problem is already present in a few existing
> places, but it shouldn't be. I suggest this remediation:
>
>> +               tss->buflen1 = Max(len1 + 1, Min(tss->buflen1 * 2, (int) MaxAllocSize));
>
> I too would very much prefer to not repeat that debate.  :-)

Committed that way.  As the patch is by and large the same as what I
submitted for this originally, I credited myself as first author and
you as second author.  I hope that seems fair.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 9.5: Memory-bounded HashAgg
Next
From: Tom Lane
Date:
Subject: Re: jsonb format is pessimal for toast compression