Re: [PERFORM] Quad processor options

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