Re: Avoiding repeated snapshot computation

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Avoiding repeated snapshot computation
Дата
Msg-id 4ED3F6610200002500043593@gw.wicourts.gov
обсуждение исходный текст
Ответ на Avoiding repeated snapshot computation  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Ответы Re: Avoiding repeated snapshot computation  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Список pgsql-hackers
Andres Freund  wrote:
> I would like to see somebody running a benchmark on a machine with
> higher concurrency...
Yeah, me too.  I don't find it at all hard to believe that we will
see significant performance benefit by changing the PGPROC structure
so that all parts of it can be accessed through one cache line rather
than two.  The fact that we saw improvement when changing it down to
two, even though there is extra indirection in some places, seems
like pretty solid evidence on the face of it.
I went in to the office on Sunday to try to get a few hours of
benchmarks for this on our new monster machine, but the DBA
responsible for putting it into production was on it first, loading
it with production data.  At this point it will get really hard to
schedule any more of the 20-hour runs that were the basis of most of
my recent numbers, but I may be able to shut down production use for
a two or three hour window on a weekend to run an abbreviated set,
focusing on the higher concurrency levels.  Ideally that would be on
top of the other pending performance patches.
Based on my earlier rounds of benchmarking, I expect that this
approach will show the greatest benefit at the higher concurrency
levels, where cache lines are most stressed.
-Kevin


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: perltidy
Следующее
От: Nathan Boley
Дата:
Сообщение: Re: WIP: collect frequency statistics for arrays