Skip site navigation (1) Skip section navigation (2)

Re: profiling pgbench

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: profiling pgbench
Date: 2010-11-24 22:33:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Nov 24, 2010 at 1:19 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On Wednesday 24 November 2010 22:14:04 Andres Freund wrote:
>> On Wednesday 24 November 2010 21:24:43 Robert Haas wrote:
>> Recarding LWLockAcquire costs:
>> Yes, its pretty noticeable - on loads of different usages. On a bunch of
>> production machines its the second (begind XLogInsert) on some the most
>> expensive function. Most of the time

> AllocSetAlloc is the third, battling with hash_search_with_hash value. To
> complete that sentence...

I've played a bit with hash_search_with_hash_value and found that most
of the time is spent on shared hash tables, not private ones.  And the
time attributed to it for the shared hash tables mostly seems to be
due to the time it takes to fight cache lines away from other CPUs.  I
suspect the same thing is true of LWLockAcquire.



In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-11-24 22:34:46
Subject: Re: profiling pgbench
Previous:From: Robert HaasDate: 2010-11-24 22:30:49
Subject: Re: profiling connection overhead

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group