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

From Andrew Gierth
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id 87vbjzkbsz.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
>>>>> "Peter" == Peter Geoghegan <pg@heroku.com> writes:
Peter> Okay, then. I concede the point: We should support the datumPeter> case as you outline, since it is simpler than
anyPeter>alternative. It probably won't even be necessary to formalizePeter> the idea that finished abbreviated keys
mustbe pass-by-valuePeter> (at least not for the benefit of this functionality); if someonePeter> writes an opclass
thatgenerates pass-by-reference abbreviatedPeter> keys (I think that might actually make sense, although I'm
beingPeter>imaginative), it simply won't work for the datum sort case,Peter> which is probably fine.
 

I don't see why a by-reference abbreviated key would be any more of an
issue for the datum sorter than for anything else. In either case you'd
just get excess memory usage (any memory allocated by the abbreviation
function for the result won't be charged against work_mem and won't be
freed until the sort ends).

What matters for the datum sorter (and not for the others) is that we
not try and abbreviate a by-value type (since we only have an allocated
copy of the value if it was by-reference); this is handled in the code
by just not asking for abbreviation in such cases.
Peter> Are you going to submit this to the final commitfest? I'llPeter> review it if you do.

I'll post a cleaned-up version after the existing issues are fixed.

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Next
From: Bruce Momjian
Date:
Subject: Re: Temporal features in PostgreSQL