Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

On Fri, Jun 1, 2012 at 3:16 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> Ok, now you've lost me. If the read() blocks, how on earth can a few
> additional pins/unpins ever account for any meaningful execution time?
>
> It seems to me that once read() blocks we're talking about a delay in the
> order of the scheduling granularity (i.e., milliseconds, in the best case),
> while even in the word case pinning a buffer shouldn't take more than
> 1000 cycles (for comparison, I think a cache miss across all layers costs
> a few hundred cycles). So there's at the very least 3 order of magnitude
> between those two...

I'm not sure what you want me to say here. s_lock shows up in the
profile, and some of that is from PinBuffer. I think any detectable
number of calls to s_lock is a sign of Bad Things (TM). I can't
reproduce anything as severe as what the OP is seeing, but what does
that prove? In a couple years we'll have systems with 128 cores
floating around, and things that are minor problems at 32 or even 64
cores will be crippling at 128 cores. IME, spinlock contention has a
very sharp tipping point. It's only a minor annoyance and then you
hit some threshold number of cores and, bam, you're spending 70-90% of
your time across all cores fighting over that one spinlock.

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