X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 914D09DCB74
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue, 21 Mar 2006 13:49:06 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 24931-06
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue, 21 Mar 2006 13:49:05 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from noel.decibel.org (noel.decibel.org [67.100.216.10])
	by postgresql.org (Postfix) with ESMTP id 29C529DCAA7
	for <pgsql-performance@postgresql.org>;
	Tue, 21 Mar 2006 13:49:04 -0400 (AST)
Received: by noel.decibel.org (Postfix, from userid 1001)
	id 7AAD656431; Tue, 21 Mar 2006 11:49:04 -0600 (CST)
Received: (hashcash-sendmail, from uid 1001); Tue, 21 Mar 2006 11:49:03 -0600
Date: Tue, 21 Mar 2006 11:49:03 -0600
From: "Jim C. Nasby" <jnasby@pervasive.com>
To: Guillaume Cottenceau <gc@mnc.ch>
Cc: pgsql-performance@postgresql.org
Subject: Re: planner with index scan cost way off actual cost,
Message-ID: <20060321174903.GG15742@pervasive.com>
References: <87ek11gz69.fsf@meuh.mnc.lan> <441CDAAA.20609@paradise.net.nz>
	<87d5ghms3h.fsf@meuh.mnc.lan>
	<20060321095049.GW15742@pervasive.com>
	<441FD82D.1040509@paradise.net.nz>
	<20060321115100.GM15742@pervasive.com>
	<87acbkkl0o.fsf@meuh.mnc.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87acbkkl0o.fsf@meuh.mnc.lan>
X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64
X-Distributed: Join the Effort!  http://www.distributed.net
User-Agent: Mutt/1.5.11
X-Hashcash: 1:20:060321:gc@mnc.ch::xSNFuKTlMrbg6b0s:000000006BKh
X-Hashcash: 
 1:20:060321:pgsql-performance@postgresql.org::un3FsgXBY7UcHvFT:00000
	0000000000000000000000003W2U
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.108 required=5 tests=[AWL=0.108]
X-Spam-Score: 0.108
X-Spam-Level: 
X-Archive-Number: 200603/414
X-Sequence-Number: 17851

On Tue, Mar 21, 2006 at 02:03:19PM +0100, Guillaume Cottenceau wrote:
> "Jim C. Nasby" <jnasby 'at' pervasive.com> writes:
> 
> > On Tue, Mar 21, 2006 at 10:40:45PM +1200, Mark Kirkwood wrote:
> > > I was going to recommend higher - but not knowing what else was running, 
> > > kept it to quite conservative :-)... and given he's running java, the 
> > > JVM could easily eat 512M all by itself!
> > 
> > Oh, didn't pick up on java being in the mix. Yeah, it can be a real pig.
> > I think people often place too much emphasis on having a seperate
> > application server, but in the case of java you often have no choice.
> 
> Fortunately the servers use 2G or 4G of memory, only my test
> machine had 1G, as I believe I precised in a message; so I'm
> definitely going to use Mark's advices to enlarge a lot the
> shared buffers. Btw, what about sort_mem? I have seen it only
> little referenced in the documentation.

The biggest issue with setting work_mem (you're not doing current
development on 7.4 are you?) is ensuring that you don't push the server
into swapping. Remember that work_mem controls how much memory can be
used for EACH sort or hash (maybe others) operation. Each query can
consume multiples of work_mem (since it can do multiple sorts, for
example), and of course each backend could be running a query at the
same time. Because of all this it's pretty difficult to make work_mem
recomendations without knowing a lot more about your environment.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461