Re: reducing the overhead of frequent table locks - now, with WIP patch

On 05.06.2011 22:04, Stefan Kaltenbrunner wrote:
> and one for the -j80 case(also patched).
>
>
> 485798   48.9667  postgres                 s_lock
> 60327     6.0808  postgres                 LWLockAcquire
> 57049     5.7503  postgres                 LWLockRelease
> 18357     1.8503  postgres                 hash_search_with_hash_value
> 17033     1.7169  postgres                 GetSnapshotData
> 14763     1.4881  postgres                 base_yyparse
> 14460     1.4575  postgres                 SearchCatCache
> 13975     1.4086  postgres                 AllocSetAlloc
> 6416      0.6467  postgres                 PinBuffer
> 5024      0.5064  postgres                 SIGetDataEntries
> 4704      0.4741  postgres                 core_yylex
> 4625      0.4662  postgres                 _bt_compare

Hmm, does that mean that it's spending 50% of the time spinning on a 
spinlock? That's bad. It's one thing to be contended on a lock, and have 
a lot of idle time because of that, but it's even worse to spend a lot 
of time spinning because that CPU time won't be spent on doing more 
useful work, even if there is some other process on the system that 
could make use of that CPU time.

I like the overall improvement on the throughput, of course, but we have 
to find a way to avoid the busy-wait.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com