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@topconcepts.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@aon.at>
To: "Henrik Steffen" <steffen@city-map.de>
Cc: <pgsql-general@postgresql.org>; <pgsql-performance@postgresl.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@city-map.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
>