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

Re: profiling pgbench

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: profiling pgbench
Date: 2010-11-24 22:49:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> 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.

That squares with some behavior I've seen.  If you run opannotate
you often see ridiculously high time percentages attributed to extremely
trivial C statements.  The explanation seems to be that those places are
where chunks of memory are first touched, and have to be pulled into the
CPU's cache (and, if in shared memory, pulled away from some other CPU).

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Александър ШоповDate: 2010-11-24 22:53:31
Subject: Re: Workarounds for getBinaryStream returning ByteArrayInputStream on bytea
Previous:From: Bruce MomjianDate: 2010-11-24 22:48:40
Subject: Re: [HACKERS] pgsql: Remove useless whitespace at end of lines

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