On Tue, Dec 2, 2014 at 5:16 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Tue, Dec 2, 2014 at 2:07 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Well, maybe you should make the updates we've agreed on and I can take
>> another look at it.
>
> Agreed.
>
>> But I didn't think that I was proposing to change
>> anything about the level at which the decision about whether to
>> abbreviate or not was made; rather, I thought I was suggesting that we
>> pass that flag down to the code that initializes the sortsupport
>> object as an argument rather than through the sortsupport structure
>> itself.
>
> The flag I'm talking about concerns the *applicability* of
> abbreviation, and not whether or not it will actually be used (maybe
> the opclass lacks support, or decides not to for some platform
> specific reason). Tuplesort has a contract with abbreviation +
> sortsupport that considers whether or not the function pointer used to
> abbreviate is set, which relates to whether or not abbreviation will
> *actually* be used. Note that for non-abbreviation-applicable
> attributes, btsortsupport_worker() never sets the function pointer
> (nor, incidentally, does it set the other abbreviation related
> function pointers in the struct).
Right, and what I'm saying is that maybe the "applicability" flag
shouldn't be stored in the SortSupport object, but passed down as an
argument.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
