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 <[EMAIL PROTECTED]> > > 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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
