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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Дата
Msg-id CAH2-Wzkx0RJy1kUXFF9Vwhgezoio8shUbFf5gqAUpHpxBi3zVw@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()  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Feb 10, 2020 at 1:05 AM Floris Van Nee <florisvannee@optiver.com> wrote:
> I ran all the tests on two different machines, several times for 1 hour each time. I'm still having a hard time
gettingreliable results for the 30 clients case though. I'm pretty certain the patches bring a performance benefit, but
howhigh exactly is difficult to say. As for applying only patch 1+2 or all three patches - I found no significant
differencebetween these two cases. It looks like all the performance benefit is in the first two patches. 

Attached is v3, which no longer includes the third patch/optimization.
It also inlines (in the second patch) by marking the _bt_compare
definition as inline, while not changing anything in nbtree.h. I
believe that this is portable C99 -- let's see what CF Tester thinks
of it.

I'm going to test this myself. It would be nice if you could repeat
something like the previous experiments with v3, Floris. master vs v3
(both patches together). With a variable number of clients.

Thanks
--
Peter Geoghegan

Вложения

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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: PL/Python - lifetime of variables?
Следующее
От: Amit Langote
Дата:
Сообщение: Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side