Re: Upgrade to dual processor machine?

of course, there are some seq scans... one of the most
difficult queries is for example a kind of full text
search, that searches through 8 different tables with
each between 300.000 and 500.000 rows and 5-50 columns,
but that's a different issue (need a full-text-search-engine...)

I will do some experiments with both camps you described

Thanks to all of you who wrote answers to this thread

It has helped me a huge lot !

--

Mit freundlichem Gruß

Henrik Steffen
Geschäftsführer

top concepts Internetmarketing GmbH
Am Steinkamp 7 - D-21684 Stade - Germany
--------------------------------------------------------
http://www.topconcepts.com Tel. +49 4141 991230
mail: steffen(at)topconcepts(dot)com Fax. +49 4141 991233
--------------------------------------------------------
24h-Support Hotline: +49 1908 34697 (EUR 1.86/Min,topc)
--------------------------------------------------------
Ihr SMS-Gateway: JETZT NEU unter: http://sms.city-map.de
System-Partner gesucht: http://www.franchise.city-map.de
--------------------------------------------------------
Handelsregister: AG Stade HRB 5811 - UstId: DE 213645563
--------------------------------------------------------

----- Original Message -----
From: "Manfred Koizar" <mkoi-pg(at)aon(dot)at>
To: "Henrik Steffen" <steffen(at)city-map(dot)de>
Cc: <pgsql-general(at)postgresql(dot)org>; <pgsql-performance(at)postgresl(dot)org>
Sent: Thursday, November 14, 2002 6:15 PM
Subject: Re: [GENERAL] Upgrade to dual processor machine?

> On Thu, 14 Nov 2002 11:03:54 +0100, "Henrik Steffen"
> <steffen(at)city-map(dot)de> wrote:
> >this is how it looks like, when my system is busy (right now!!!)
> >vmstat 1 5:
> > procs memory swap io system cpu
> > r b w swpd free buff cache si so bi bo in cs us sy id
> > 1 8 1 60 4964 5888 309684 0 0 176 74 16 32 25 9 66
> > 0 6 3 60 4964 5932 308772 0 0 6264 256 347 347 13 9 78
> > 0 5 1 60 4964 5900 309364 0 0 9312 224 380 309 11 6 83
> > 1 4 1 60 5272 5940 309152 0 0 10320 116 397 429 17 6 77
> > 1 4 1 60 4964 5896 309512 0 0 11020 152 451 456 14 10 76
>
> More than 10000 disk blocks coming in per second looks quite
> impressive, IMHO. (I wonder if this is due to seq scans?) But the
> cpu idle column tells us that you are not CPU bound any more.
>
>
> >free:
> > total used free shared buffers cached
> >Mem: 1020808 1015860 4948 531424 5972 309548
> >-/+ buffers/cache: 700340 320468
> >Swap: 1028112 60 1028052
>
> There are two camps when it comes to PG shared buffers: (a) set
> shared_buffers as high as possible to minimize PG buffer misses vs.
> (b) assume that transfers between OS and PG buffers are cheap and
> choose a moderate value for shared_buffers ("in the low thousands") to
> let the operating system's disk caching do its work.
>
> Both camps agree that reserving half of your available memory for
> shared buffers is a Bad Thing, because whenever a page cannot be found
> in PG's buffers it is almost certainly not in the OS cache and has to
> be fetched from disk. So half of your memory (the OS cache) is wasted
> for nothing.
>
> FYI, I belong to the latter camp and I strongly feel you should set
> shared_buffers to something near 4000.
>
> Servus
> Manfred
>