Re: Wait free LW_SHARED acquisition - v0.2 - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Wait free LW_SHARED acquisition - v0.2
Date
Msg-id CAMkU=1xiAYXxaBMGZ9DVzZRGggv0Jk4hz3CAmR87S+zyucvqEA@mail.gmail.com
Whole thread Raw
In response to Re: Wait free LW_SHARED acquisition - v0.2  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Sun, Feb 2, 2014 at 6:00 AM, Andres Freund <andres@2ndquadrant.com> wrote:

Some background:
The setups that triggered me into working on the patchset didn't really
have a pgbench like workload, the individual queries were/are more
complicated even though it's still an high throughput OLTP workload. And
the contention was *much* higher than what I can reproduce with pgbench
-S, there was often nearly all time spent in the lwlock's spinlock, and
it was primarily the buffer mapping lwlocks, being locked in shared
mode. The difference is that instead of locking very few buffers per
query like pgbench does, they touched much more.


Perhaps I should try to argue for this extension to pgbench again:


I think it would go a good job of exercising what you want, provided you set the scale so that all data fit in RAM but not in shared_buffers.  

Or maybe you want it to fit in shared_buffers, since the buffer mapping lock was contended in shared mode--that suggests the problem is finding the buffer that already has the page, not making a buffer to have the page.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: plpgsql.warn_shadow
Next
From: Peter Geoghegan
Date:
Subject: Re: Misaligned BufferDescriptors causing major performance problems on AMD