On Sat, Nov 01, 2003 at 10:29:34PM +0100, Manfred Spraul wrote:Cool.
Mark Wong wrote:
Yeah, my dbt2 applications are multithreaded.Do you need SIGPIPE delivery in your app? If no, could you try what happens if you apply the attached patch to postgres, and perform the
signal(SIGPIPE, SIG_IGN);
once in your dbt2 app?
Wow, that patch made a pretty big difference: http://developer.osdl.org/markw/dbt2-pgsql/191/ - metric 1605.51
So no one has to look for older mail before I applied that patch: http://developer.osdl.org/markw/dbt2-pgsql/190/ - metric 1427.24
Looks like about a 12% improvement in the overall metric. The first thing I noticed is that do_sigaction in the kernel profile almost disappeared.
TheI've looked at the profile:
top few functions in the database profile doesn't appear to have changed much.
The only unusal line is the memcpy(cur_skey, cache->cc_skey, sizeof(cur_skey)): it copies 144 byte and needs ~5.3% global cpu time, from the 12.1% in SearchCatCache. The cachelines (line size 128 bytes) of cc_skey are shared with cc_bucket. 1.8% cpu time is spent in DLMoveToFront, the function that moves cache entries around.
Perhaps a scalability problem of the hash table? The implementation moves the entries around all the time, i.e. the worst case for cache line transfers.
-- Manfred
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
