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

On Tue, Jan 20, 2015 at 7:07 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Tue, Jan 20, 2015 at 3:57 PM, Peter Geoghegan <pg@heroku.com> wrote:
>> It's certainly possible to fix Andrew's test case with the attached.
>> I'm not sure that that's the appropriate fix, though: there is
>> probably a case to be made for not bothering with abbreviation once
>> we've read tuples in for the final merge run. More likely, the
>> strongest case is for storing the abbreviated keys on disk too, and
>> reading those back.
>
> Maybe not, though: An extra 8 bytes per tuple on disk is not free.
> OTOH, if we're I/O bound on the final merge, as we ought to be, then
> recomputing the abbreviated keys could make sense, since there may
> well be an idle CPU core anyway.

I was assuming we were going to fix this by undoing the abbreviation
(as in the abort case) when we spill to disk, and not bothering with
it thereafter.

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