Re: B-Tree support function number 3 (strxfrm() optimization)
От | Peter Geoghegan |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | CAM3SWZSoRvJ+-Bh4B_ux3Hgx4Vsep3YWbMTveCguCJbhcmKHnw@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)
|
Список | pgsql-hackers |
On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Most places that use a SortSupportData initialize ssup.position > explicitly, but tuplesort_begin_datum() doesn't. That's an > inconsistency that should be fixed, but I'm not sure which direction > is best. I'm not sure what you mean. tuplesort_begin_datum() only uses/initializes the Tuplesortstate.onlyKey field, and in fact that did have its ssup.position initialized to zero in the last revision. This indicates that we should not apply the optimization, because: /** Conversion to abbreviated representation infeasible in the Datum case.* It must be possible to subsequently fetch originaldatum values within* tuplesort_getdatum(), which would require special-case preservation of* original values thatwe prefer to avoid.*/ state->onlyKey->position = sortKeyOther; -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: