| 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: | AANLkTimioMewG=fyNdfWOU=VTN+qPuw5LemgxDPBCNZ8@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-11-24 22:34:46 | Re: profiling pgbench |
| Previous Message | Robert Haas | 2010-11-24 22:30:49 | Re: profiling connection overhead |