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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: B-Tree support function number 3 (strxfrm() optimization)
Дата
Msg-id CA+TgmobxT9=NZnZBLEWAh2spErbwpAtjT=eEY9VHOfarvOV92g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On Thu, Sep 25, 2014 at 3:17 PM, Peter Geoghegan <pg@heroku.com> wrote:
>> To find out how much that optimization buys, you
>> should use tuples with many variable-length columns (say, 50)
>> preceding the text column you're sorting on. I won't be surprised if
>> that turns out to be expensive enough to be worth worrying about, but
>> I have not benchmarked it.
>
> Sorry, but I don't follow. I don't think the pertinent question is if
> it's a noticeable cost. I think the pertinent question is if it's
> worth it. Doing something about it necessitates a lot of extra memory
> access. Not doing something about it hardly affects the amount of
> memory access required, perhaps not at all.

I think you're mincing words.  If you go back and fix datum1, you'll
spend a bunch of effort doing that.    If you don't, you'll pay a cost
on every comparison to re-find the relevant column inside each tuple.
You can compare those costs in a variety of cases, including the one I
mentioned, where the latter cost will be relatively high.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Review of GetUserId() Usage
Следующее
От: Andres Freund
Дата:
Сообщение: Re: END_OF_RECOVERY shutdowns and ResetUnloggedRelations()