profiling connection overhead

Per previous threats, I spent some time tonight running oprofile
(using the directions Tom Lane was foolish enough to provide me back
in May).  I took testlibpq.c and hacked it up to just connect to the
server and then disconnect in a tight loop without doing anything
useful, hoping to measure the overhead of starting up a new
connection.  Ha, ha, funny about that:

120899   18.0616  postgres                 AtProcExit_Buffers
56891     8.4992  libc-2.11.2.so           memset
30987     4.6293  libc-2.11.2.so           memcpy
26944     4.0253  postgres                 hash_search_with_hash_value
26554     3.9670  postgres                 AllocSetAlloc
20407     3.0487  libc-2.11.2.so           _int_malloc
17269     2.5799  libc-2.11.2.so           fread
13005     1.9429  ld-2.11.2.so             do_lookup_x
11850     1.7703  ld-2.11.2.so             _dl_fixup
10194     1.5229  libc-2.11.2.so           _IO_file_xsgetn

In English: the #1 overhead here is actually something that happens
when processes EXIT, not when they start.  Essentially all the time is
in two lines:
56920  6.6006 :        for (i = 0; i < NBuffers; i++)              :        {98745 11.4507 :                if
(PrivateRefCount[i]!= 0)
 

Non-default configs:

max_connections = 100
shared_buffers = 480MB
work_mem = 4MB
maintenance_work_mem = 128MB
checkpoint_segments = 30
random_page_cost = 2.0

Anything we can do about this?  That's a lot of overhead, and it'd be
a lot worse on a big machine with 8GB of shared_buffers.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company