Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
| От | Kevin Grittner |
|---|---|
| Тема | Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
| Дата | |
| Msg-id | CACjxUsMMsSDQTDjdzKY9TwaurN_gNS3Du3kpE5zU5w_AagRmjw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Re: [COMMITTERS] pgsql: Avoid extra locks in
GetSnapshotData if old_snapshot_threshold <
Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
| Список | pgsql-hackers |
On Wed, Apr 13, 2016 at 3:01 PM, Andres Freund <andres@anarazel.de> wrote: > If you want me to rn some other tests I can, but ISTM we have the > data we need? Thanks for the additional detail on how this was run. I think I still need a little more context, though: What is the kernel on which these tests were run? Which pg commit were these tests run against? If 2201d801 was not included in your -1 tests, have you identified where the 2% extra run time is going on -1 versus reverted? Since several other threads lately have reported bigger variation than that based on random memory alignment issues, can we confirm that this is a real difference in what is at master's HEAD? Of course, I'm still scheduled to test on bare metal machines in a couple days, on two different architectures, so we'll have a few more data points after that. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: