Re: B-Tree support function number 3 (strxfrm() optimization)

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: B-Tree support function number 3 (strxfrm() optimization)
Дата
Msg-id 87vbjzkbsz.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
>>>>> "Peter" == Peter Geoghegan <pg@heroku.com> writes:
Peter> Okay, then. I concede the point: We should support the datumPeter> case as you outline, since it is simpler than
anyPeter>alternative. It probably won't even be necessary to formalizePeter> the idea that finished abbreviated keys
mustbe pass-by-valuePeter> (at least not for the benefit of this functionality); if someonePeter> writes an opclass
thatgenerates pass-by-reference abbreviatedPeter> keys (I think that might actually make sense, although I'm
beingPeter>imaginative), it simply won't work for the datum sort case,Peter> which is probably fine.
 

I don't see why a by-reference abbreviated key would be any more of an
issue for the datum sorter than for anything else. In either case you'd
just get excess memory usage (any memory allocated by the abbreviation
function for the result won't be charged against work_mem and won't be
freed until the sort ends).

What matters for the datum sorter (and not for the others) is that we
not try and abbreviate a by-value type (since we only have an allocated
copy of the value if it was by-reference); this is handled in the code
by just not asking for abbreviation in such cases.
Peter> Are you going to submit this to the final commitfest? I'llPeter> review it if you do.

I'll post a cleaned-up version after the existing issues are fixed.

-- 
Andrew (irc:RhodiumToad)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: B-Tree support function number 3 (strxfrm() optimization)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Temporal features in PostgreSQL