Overhead for stats_command_string et al, take 2
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
Greg Stark <gsstark@mit.edu> writes:
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.
No --- I strace'd the backend and nothing is going back and forth except
"SELECT 1;" and the response to that. I would think the extra BEGINs
would lead to far more overhead than I'm seeing anyway.
why is anything calling htonl at all?
Protocol message-length words and suchlike, no doubt.
regards, tom lane