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 87d269n0wl.fsf@news-spur.riddles.org.uk
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
>>>>> "Robert" == Robert Haas <robertmhaas@gmail.com> writes:
Robert> All right, it seems Tom is with you on that point, so afterRobert> some study, I've committed this with very
minormodifications.
 

This caught my eye (thanks to conflict with GS patch):
* In the future, we should consider forcing the* tuplesort_begin_heap() case when the abbreviated key* optimization can
therebybe used, even when numInputs is 1.
 

The comment in tuplesort_begin_datum that abbreviation can't be used
seems wrong to me; why is the copy of the original value pointed to by
stup->tuple (in the case of by-reference types, and abbreviation is
obviously not needed for by-value types) not sufficient?

Or what am I missing?

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Ali Akbar
Date:
Subject: Re: PATCH: decreasing memory needlessly consumed by array_agg
Next
From: Amit Kapila
Date:
Subject: Re: Parallel Seq Scan