Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Oh, good point. Do we remove stats_command_string?
>
> You mean, remove the option to turn it off? I don't think so. Aside
> from whatever remaining overhead there is, there's a possible security
> argument to be made that one migh
I ran your test with all defaults in 8.1 and CVS HEAD on a BSD/OS dual
Xeon and got:
8.1.X 1.946
HEAD1.986
I ran the test ten times on three runs and took the middle value.
It is a slowdown of 2%. I used these configure options:
configure \
--with
Tom Lane wrote:
> I wrote:
> > IIRC, newer BSDen use a kernel call for this, so you should be able to
> > measure it on your own machine. Just tweak ps_status.c to force it to
> > select PS_USE_NONE instead of PS_USE_SETPROCTITLE to generate a
> > comparison case. I'll try it on my old HPUX box t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yep, I see 8% here. I will add a patch to allow the ps display to be
> turned off.
I think we'd still want a backend to set the PS display once with its
identification data (user/DB name and client address). It's just the
transient activity updates tha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oh, good point. Do we remove stats_command_string?
You mean, remove the option to turn it off? I don't think so. Aside
from whatever remaining overhead there is, there's a possible security
argument to be made that one might not want one's commands ex
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yep, I see 8% here. I will add a patch to allow the ps display to be
> > turned off.
>
> I think we'd still want a backend to set the PS display once with its
> identification data (user/DB name and client address). It's just the
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Average of 5 runs, for the first two cases, on the x86 machine that
> shows high overhead in gettimeofday.
> I used only 3 SELECT 1 queries instead of 100k.
> 3 SELECT 1;
> HEAD8.1
> no overhead 2
Tom Lane wrote:
> I redid my previous measurements after finishing up the weekend's
> hacking. The numbers shown below are elapsed time in seconds for
>
> time psql -f testfile.sql postgres >/dev/null
Average of 5 runs, for the first two cases, on the x86 machine that
shows high overhead i
Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
It'd be interesting to compare 8.1 and HEAD for the no-overhead case;
I don't think you need to redo all four cases, but I'd like to see that one.
8.1:50,50,49
HEAD: 49,48,49
OK, so that seems comparable
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Seeing stats_command_string with almost zero overhead is great news!
> Should we remove that setting and just have it enabled all
> the time?
If you don't need it, you shouldn't have to pay any overhead for it,
I think. One could make an argument now fo
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It'd be interesting to compare 8.1 and HEAD for the no-overhead case;
> >> I don't think you need to redo all four cases, but I'd like to see that
> >> one.
>
> > 8.1:50,50,49
> > HEAD: 49,48
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It'd be interesting to compare 8.1 and HEAD for the no-overhead case;
>> I don't think you need to redo all four cases, but I'd like to see that one.
> 8.1: 50,50,49
> HEAD: 49,48,49
OK, so that seems comparable to my results
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Or do you mean that you have stats_row_level and/or stats_block_level on
>>> in all four cases?
>
>> yes - stats_row_level and stats_block_level on in all cases (sorry for
>> the confusion) - I can easily red
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Or do you mean that you have stats_row_level and/or stats_block_level on
>> in all four cases?
> yes - stats_row_level and stats_block_level on in all cases (sorry for
> the confusion) - I can easily redo the tests without those
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> This is what I get on a fast AMD Dual Opteron box(Running Debian
>> Sarge/AMD64):
>
>>8.1.4 HEAD
>> 100 SELECT 1;74,74,7377,76,77
>> stats_command_string=1;
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> This is what I get on a fast AMD Dual Opteron box(Running Debian
> Sarge/AMD64):
> 8.1.4 HEAD
> 100 SELECT 1; 74,74,7377,76,77
> stats_command_string=1; 105,99,106
Tom Lane wrote:
> 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
> s
Sorry I am traveling for EnterpriseDB Wednesday and Thursday so I can't
run the tests right now.
Seeing stats_command_string with almost zero overhead is great news!
Should we remove that setting and just have it enabled all
the time?
As far as pg_stat_activity.query_start, I never suspected tha
Greg Stark <[EMAIL PROTECTED]> 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 an
> 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 wa
I wrote:
> BTW, according to "top" the CPU usage percentages in these tests are
> on the order of 55% backend, 45% psql. Methinks psql needs a round
> of performance tuning ...
oprofile tells the tale:
CPU: P4 / Xeon with 2 hyper-threads, speed 2793.03 MHz (estimated)
Counted GLOBAL_POWER_EVENTS
I redid my previous measurements after finishing up the weekend's
hacking. The numbers shown below are elapsed time in seconds for
time psql -f testfile.sql postgres >/dev/null
using CVS HEAD and REL8_1_STABLE branch tip, compiled --enable-debug
--disable-cassert, no nondefault options e
22 matches
Mail list logo
