On Mon, Jan 6, 2014 at 2:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> Well, I took a look at this and it turns out not to be very hard, so
>> here's a patch.  Currently, we allocate 3 semaphore per shared buffer
>> and a bunch of others, but the 3 per shared buffer dominates, so you
>> end up with ~49k spinlocks for the default of 128MB shared_buffers.  I
>> chose to peg the number of semaphores at 1024, which is quite small
>> compared to the current allocation, but the number of spinlock
>> allocations that can be in progress at any given time is limited by
>> the number of running backends.  Even allowing for the birthday
>> paradox, that should be enough to run at least a few dozen backends
>> without suffering serious problems due to the multiplexing -
>> especially because in real workloads, contention is usually
>> concentrated around a small number of spinlocks that are unlikely to
>> all be mapped to the same underlying semaphore.
>> I'm happy enough with this way forward.  Objections?
> -1 for the any_spinlock_held business (useless overhead IMO, as it doesn't
> have anything whatsoever to do with enforcing the actual coding rule).

Hmm.  I thought that was a pretty well-aimed bullet myself; why do you
think that it isn't?  I don't particularly mind ripping it out, but it
seemed like a good automated test to me.

> And I'd suggest defining NUM_SPINLOCK_SEMAPHORES in pg_config_manual.h,
> and maybe dropping SpinlockSemas() altogether in favor of just referencing
> the constant.  Otherwise this seems reasonable.

As far as pg_config_manual.h is concerned, is this the sort of thing
you have in mind?


Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to