Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Дата
Msg-id CAH2-Wzm1bnfppJDyXS4-DB0b5=s_bexaCdqdQpqKpjtZFOe27A@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Floris Van Nee <florisvannee@Optiver.com>)
Ответы RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Floris Van Nee <florisvannee@Optiver.com>)
Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список pgsql-hackers
On Sun, Mar 1, 2020 at 12:15 PM Floris Van Nee <florisvannee@optiver.com> wrote:
> Minor conflict with that patch indeed. Attached is rebased version. I'm running some tests now - will post the
resultshere when finished.
 

Thanks.

We're going to have to go back to my original approach to inlining. At
least, it seemed to be necessary to do that to get any benefit from
the patch on my comparatively modest workstation (using a similar
pgbench SELECT benchmark to the one that you ran). Tom also had a
concern about the portability of inlining without using "static
inline" -- that is another reason to avoid the approach to inlining
taken by v3 + v4.

It's possible (though not very likely) that performance has been
impacted by the deduplication patch (commit 0d861bbb), since it
updated the definition of BTreeTupleGetNAtts() itself.

Attached is v5, which inlines in a targeted fashion, pretty much in
the same way as the earliest version. This is the same as v4 in every
other way. Perhaps you can test this.

-- 
Peter Geoghegan

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: ALTER tbl rewrite loses CLUSTER ON index
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Symbolic names for the values of typalign and typstorage