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 | CACjxUsO_B8yQcA=ZhDh1Zn3Z+McgJZP0jcbvFRmuLup8XQkudQ@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 <
|
Список | pgsql-hackers |
On Wed, Apr 13, 2016 at 10:01 AM, Andres Freund <andres@anarazel.de> wrote: > My problem with that is that snapshot-too-old is essentially a > efficiency feature for busy and large databases. Regressing noticeably > when it's enabled in it's natural habitat seems sad. With a real-world application with realistic simulated user load there was no such regression and a big gain in performance over time, so we're talking about adjusting how broad a range of workloads it benefits. I don't have a strong opinion yet, since I haven't run the benchmarks on big machines (scheduled for the day after tomorrow); but as an example, if I only see such regression on a Linux kernel with version a version < 3.8 I am going to be less concerned about getting something into 9.6, since IMO it is completely irresponsible to run a NUMA machine with 4 or more nodes on an OS with a substandard NUMA scheduler. I'm not sure when 3.8 became available, but according to Wikipedia Version 3.10 of the Linux kernel was released in June 2013, so it's not like you need to be on the bleeding edge to have a decent scheduler. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: