On Tue, Dec 2, 2014 at 4:21 PM, Peter Geoghegan <pg@heroku.com> wrote:
>>> I'm not sure about that. I'd prefer to have tuplesort (and one or two
>>> other sites) set the "abbreviation is possible in principle" flag.
>>> Otherwise, sortsupport needs to assume that the leading attribute is
>>> going to be the abbreviation-applicable one, which might not always be
>>> true. Still, it's not as if I feel strongly about it.
>>
>> When wouldn't that be true?
>
> It just feels a bit wrong to me. There might be a future in which we
> want to use the datum1 field for a non-leading attribute. For example,
> when it is known ahead of time that there are low cardinality integers
> in the leading key/attribute. Granted, that's pretty speculative, but
> then it's not as if I'm insisting that it must be done that way. I
> defer to you.
Well, maybe you should make the updates we've agreed on and I can take
another look at it. 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
