| 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: | 23876.1290638982@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Александър Шопов | 2010-11-24 22:53:31 | Re: Workarounds for getBinaryStream returning ByteArrayInputStream on bytea |
| Previous Message | Bruce Momjian | 2010-11-24 22:48:40 | Re: [HACKERS] pgsql: Remove useless whitespace at end of lines |