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

Поиск
Список
Период
Сортировка
От Floris Van Nee
Тема RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Дата
Msg-id d7c19e8a6a3f4fc19c5dbcb979f0e6bf@opammb0561.comp.optiver.com
обсуждение исходный текст
Ответ на Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Список pgsql-hackers
> He reported that the problem went away with the patches applied. The
> following pgbench SELECT-only result was sent to me privately:
> 
> before:
> single:         tps = 30300.202363 (excluding connections establishing)
> all cores:      tps = 1026853.447047 (excluding connections establishing)
> 
> after:
> single:         tps = 31120.452919 (excluding connections establishing)
> all cores:      tps = 1032376.361006 (excluding connections establishing)
> 
> (Actually, he tested something slightly different -- he inlined
> _bt_compare() in his own way instead of using my 0002-*, and didn't use the
> 0003-* optimization at all.)
> 
> Apparently this was a large multi-socket machine. Those are hard to come by.
> 

I could do some tests with the patch on some larger machines. What exact tests do you propose? Are there some specific
postgresql.confsettings and pgbench initialization you recommend for this? And was the test above just running 'pgbench
-S'select-only with specific -T, -j and -c parameters?
 

-Floris


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_croak, or something like it?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_croak, or something like it?