On Tue, Dec 2, 2014 at 4:21 PM, Peter Geoghegan <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers