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
|
Список | 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 по дате отправления: