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

Jeff Janes <jeff.janes@gmail.com>

From: Jeff Janes <jeff.janes@gmail.com>

To: Sergey Koposov <koposov@ast.cam.ac.uk>

Cc: Robert Haas <robertmhaas@gmail.com>, Merlin Moncure <mmoncure@gmail.com>, pgsql-hackers@postgresql.org

Date: 2012-05-24T23:10:43Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Improve bulk-insert performance by keeping the current target buffer pinned
- 85e2cedf985b 8.4.0 cited

On Thu, May 24, 2012 at 3:36 PM, Sergey Koposov <koposov@ast.cam.ac.uk> wrote:
> Hi,
>
>
> On Thu, 24 May 2012, Robert Haas wrote:
>>
>> Not sure.  It might be some other LWLock, but it's hard to tell which
>> one from the information provided.
>
>
> If you could tell what's the best way to find out the info that you need,
> then I could run it reasonably quickly.

Add
#define LWLOCK_STATS
near the top of:
src/backend/storage/lmgr/lwlock.c

and recompile and run a reduced-size workload.  When the processes
exits, they will dump a lot of data about LWLock usage to the logfile.
 Generally the LWLock with the most blocks on it will be the main
culprit.

Cheers,

Jeff