Thread: Hello...

Hello...

From
Kevin Brown
Date:
I've got a small problem and thought someone here might be able to help
solve it.  Recently I upgraded one of the linux servers with PostgreSQL v7.1
from v7.0.3 to get support for OUTER JOINS amongst other things for a
project here at work (running a Snort NIDS logging to an SQL server).

My current setup:

Quad PII 450
2GB RAM
RH Linux 6.2, Kernel 2.2.16 (SMP enabled)

Under v7.0.3, if I ran multiple queries on this box they would each run on a
different processor and wouldn't impact on each others performance until I
ran more queries than CPUs.  Now when I run queries they all stay on one
processor and cause the queries to take longer by fighting for resources.

I start psql with the init script that came with the RPM (binary install
gotten from postgresql mirror):
    su -l postgres -c "LC_ALL=C /usr/bin/pg_ctl -D $PGDATA -o '-i -F' -p
/usr/bin/postmaster start >/dev/null 2>&1" < /dev/null

Is there some configuration option I need to setup to get it to work with
all 4 cpus?

Sorry if this has been asked before, but I couldn't find an answer by
searching the lists or reading through the docs.

Begin Geek Code;
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c
^=(
$m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72,@z=(64,72,$a^=12*($_%
16
-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$
h
=5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$
d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^$d>>4^
$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^
(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval

Re: Hello...

From
Tom Lane
Date:
Kevin Brown <Kevin.M.Brown@asu.edu> writes:
> Under v7.0.3, if I ran multiple queries on this box they would each run on a
> different processor and wouldn't impact on each others performance until I
> ran more queries than CPUs.  Now when I run queries they all stay on one
> processor and cause the queries to take longer by fighting for resources.

I know of no reason for that to have changed.  Afraid you'll have to do
some investigation of your own to discover the cause.

            regards, tom lane