On Wed, Nov 24, 2010 at 5:33 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Wed, Nov 24, 2010 at 1:19 PM, Andres Freund <and...@anarazel.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.
How do you get stats on that? How big is a typical cache line on modern CPUs? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
