On Tue, Dec 2, 2014 at 5:16 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Tue, Dec 2, 2014 at 2:07 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers