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.
> 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.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: