On 2016-04-13 10:31:19 -0500, Kevin Grittner wrote: > 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 think it depends very heavily on the type of application. To be affected you need a high rate of snapshot acquisitions. So lots of small statements, or possibly longer running stuff involving volatile functions (which IIRC get new snapshots continually). > 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. I don't think effect of adding a single spinlock (an exclusive lock!) in a hot path is likely to be hugely dependant on the kernel version. We've had such cases before, and felt the pain. E.g. the spinlock in the ProcArrayLock used to be a *HUGE* contention point, and it has pretty much the same acquisition pattern as this spinlock now. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
