On Sat, 13 Dec 2003, Kari Lavikka wrote:
> I evaluated pg 7.4 on our development server and it looked just fine
> but performance with production loads seems to be quite poor. Most of
> performance problems are caused by nonsensical query plans but there's
> also some strange slowness that I can't locate.
I had the same problem. I use Fedora Core 1 and after I updated
from 7.4RC1/7.4RC2 (I build my own RPMs) to 7.4 using the binary RPMs
from a mirror site and sometimes I had to restart postmaster to make
something work.
I rebuilt the src.rpm from current rawhide (7.4-5) and now
everything is ok. The guys from redhat/fedora also add some patches
(rpm-pgsql-7.4.patch seems to be the most important, the rest seem to be
for a proper compile) but I didn't have the time to test if the loss of
performance is because in the original binary RPMs from postgresql.org
the patch(es) is(are) not present, because of the compiler and optflags
used to build the RPMs are not chosed well or something else. I used gcc
3.3.2 (from FC1 distro) and the following optflags:
- On a P4 machine: optflags: i686 -O2 -g -march=pentium4 -msse2 -mfpmath=sse -fomit-frame-pointer -fforce-addr
-fforce-mem-maccumulate-outgoing-args -finline-limit=2048
- On a Celeron Tualatin: optflags: i686 -O2 -g -march=pentium3 -msse -mfpmath=sse -fomit-frame-pointer -fforce-addr
-fforce-mem-maccumulate-outgoing-args -finline-limit=2048
So, if you use the original binaries from postgresql.org try to
recompile from sources setting CFLAGS and CXXFLAGS to proper values
(maybe -msse2 -mfpmath=sse are not a good choice, you can try removing
them).
If not then review your postgresql configuration (buffers,
memory, page cost, etc), because 7.4 seems to be faster than 7.3 and
there is no reason for it to run slower on your system.
--
Any views or opinions presented within this e-mail are solely those of
the author and do not necessarily represent those of any company, unless
otherwise expressly stated.