Re: Avoiding repeated snapshot computation
От | Pavan Deolasee |
---|---|
Тема | Re: Avoiding repeated snapshot computation |
Дата | |
Msg-id | CABOikdNUupQpLLv7BY4152ehi8ynS2SXvg__uLoROZXH4+DzDA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Avoiding repeated snapshot computation ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Avoiding repeated snapshot computation
|
Список | pgsql-hackers |
On Tue, Nov 29, 2011 at 8:30 AM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > 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 think there is fundamental difference between the PGPROC patch that we did and the rearranging SnapshotData members that Andres has proposed. The PGPROC structure is a shared memory area, very heavily accessed by GetSnapshotData (and some others). There was a linear increase in the access as number of clients go up. The SnapshotData structure is mostly from a backend local memory (unless we do something what I suggested in the OP) and hence fitting that in a single cache line may or may not have much impact. We don't even guarantee that it starts at a cacheline which means in most cases it will still be spread on multiple cache lines. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: