Overhead for stats_command_string et al, take 2 - Mailing list pgsql-hackers

From Greg Stark
Subject Overhead for stats_command_string et al, take 2
Date
Msg-id 87vequ318j.fsf@stark.xeocode.com
Whole thread Raw
Responses Re: Overhead for stats_command_string et al, take 2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> The bad news is that except in the stats_command_string cases, HEAD
> is noticeably slower than 8.1 on the machine with slow gettimeofday.
> In the single-transaction test this might be blamed on the addition
> of statement_timestamp support (which requires a gettimeofday per
> statement that wasn't there in 8.1) ... but in the one-transaction-
> per-statement tests that doesn't hold water, because each branch is
> doing a gettimeofday per statement, just in different places.
> 
> Can anyone else reproduce this slowdown?  It might be only an artifact
> of these particular builds, but it's a bit too consistent in my x86 data
> to just ignore.

You don't perchance have ON_ERROR_ROLLBACK on do you? I did when I tried
testing it and ltrace shows plenty of traffic caused by that.

Even when I disable it I notice a few odd things. Aside from the rather high
number of memset calls (presumably caused by palloc0) why is anything calling
htonl at all? This is after the initial connection just executing "select 1"
over and over, no inet data types or anything like that.
  2771 memset   925 __sigsetjmp   744 strcmp   739 htonl   650 strncpy   556 memcpy   464 strcpy   462 htons   372
malloc  370 free   279 memcmp   186 __errno_location    93 strtol    93 send    93 recv    93 ntohl    93 memchr    93
gettimeofday   92 strncmp    92 sprintf
 


-- 
greg



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: UTF8 server-side on Win32?
Next
From: Tom Lane
Date:
Subject: Re: UTF8 server-side on Win32?