It appears that your CPU is 'slow' while your disk subsystem is 'fast'.
I had once such situation with 15 kRPM drives and ~500MHz Pentium III. On that
system, the best solution was to either increase effective_cache_size or
decrease random_page_cost (the latter obviously has to do with the fast disk,
the former with the lots of RAM).
In any case, proper optimization of queries always helps. :-)
Daniel
>>>Halford Dace said:
>
> On 12 May 2004, at 12:17 PM, Manfred Koizar wrote:
>
> > On Tue, 11 May 2004 15:46:25 -0700, Paul Tuckfield <paul@tuckfield.com>
> > wrote:
> >
> >> - I'll bet you have a low value for shared buffers, like 10000. On
> >> your 3G system
> >> you should ramp up the value to at least 1G (125000 8k buffers)
> >
> > In most cases this is almost the worst thing you can do. The only
> > thing
> > even worse would be setting it to 1.5 G.
> >
> > Postgres is just happy with a moderate shared_buffers setting. We
> > usually recommend something like 10000. You could try 20000, but don't
> > increase it beyond that without strong evidence that it helps in your
> > particular case.
> >
> > This has been discussed several times here, on -hackers and on
> > -general.
> > Search the archives for more information.
>
> We have definitely found this to be true here. We have some fairly
> complex queries running on a rather underpowered box (beautiful but
> steam-driven old Silicon Graphics Challenge DM). We ended up using a
> very slight increase to shared buffers, but gaining ENORMOUSLY through
> proper optimisation of queries, appropriate indices and the use of
> optimizer-bludgeons like "SET ENABLE_SEQSCAN = OFF"
>
> Hal
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org