Re: B-Tree support function number 3 (strxfrm() optimization)
От | Peter Geoghegan |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | CAM3SWZSmsUNYpUNjiQMDRwPCEfhDB5SOefFb3yLRubBs3jKZGA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: B-Tree support function number 3 (strxfrm() optimization)
Re: B-Tree support function number 3 (strxfrm() optimization) |
Список | pgsql-hackers |
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). -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: