On 2016-08-11 21:27:45 -0400, Robert Haas wrote: > On Thu, Aug 11, 2016 at 6:37 PM, Peter Geoghegan <p...@heroku.com> wrote: > > I notice that you acquire a spinlock within the implementation of > > condition variables. Is it worth any effort to consolidate the number > > of spinlock acquisitions? In other words, maybe the most common idioms > > should be baked into the ConditionVariable interface, which could save > > callers from having to use their own mutex variable. > > One thing to keep in mind is that spinlocks are extremely fast as long > as you don't have too many processes contending for them.
That's one of the conditions. The other is that the system as a whole is not overcommitted. Because then the chance of processes being put to sleep inside a spinlock increases. > With > parallel groups (or I/O-in-progress wait queues) of single digit > number of processes, I doubt that consolidating the spinlock > acquisitions will produce any measurable benefit. If we get to the > point of having parallel groups containing scores of processes, that > could change. And we have no measures to manage systemwide load with paralellism yet, I think the issue is a bit more general than the quoted paragraph. But I also think we shouldn't yet worry about it. It seems likely that the actual critical bottleneck is elsewhere for now. 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
