From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Overhead for stats_command_string et al, take 2 |
Date: | 2006-06-21 16:46:52 |
Message-ID: | 87vequ318j.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-21 17:09:38 | Re: UTF8 server-side on Win32? |
Previous Message | Alvaro Herrera | 2006-06-21 16:41:32 | UTF8 server-side on Win32? |