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 9BB129DD572
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Wed, 22 Mar 2006 04:04:36 -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 83169-07
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Wed, 22 Mar 2006 04:04:36 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from mail.mnc.ch (62-2-77-205.business.cablecom.ch [62.2.77.205])
	by postgresql.org (Postfix) with ESMTP id DAADB9DD447
	for <pgsql-performance@postgresql.org>;
	Wed, 22 Mar 2006 04:04:33 -0400 (AST)
Received: from localhost (localhost [127.0.0.1])
	by mail.mnc.ch (Postfix) with ESMTP id E0AE5A8323;
	Wed, 22 Mar 2006 09:04:42 +0100 (CET)
Received: from mail.mnc.ch ([127.0.0.1])
	by localhost (mail.test.lan [127.0.0.1]) (amavisd-new,
	port 10025) with ESMTP
	id 30380-08; Wed, 22 Mar 2006 09:04:42 +0100 (CET)
Received: from meuh.mnc.lan (62-2-77-204.business.cablecom.ch [62.2.77.204])
	by mail.mnc.ch (Postfix) with ESMTP id 7B07DA82B9;
	Wed, 22 Mar 2006 09:04:42 +0100 (CET)
Received: by meuh.mnc.lan (Postfix, from userid 1000)
	id 12D2E1835B0; Wed, 22 Mar 2006 09:04:30 +0100 (CET)
To: "Jim C. Nasby" <jnasby@pervasive.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: planner with index scan cost way off actual cost,
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>
	<20060321174903.GG15742@pervasive.com>
X-Hashcash: 
 1:20:060322:jnasby@pervasive.com::kshc8BkvFJ+6eUIc:0000000000000000000000000000000000000000038+4
X-Hashcash: 
 1:20:060322:pgsql-performance@postgresql.org::RfSIz8e9mhQAKA5c:000000000000000000000000000002CTd
From: Guillaume Cottenceau <gc@mnc.ch>
Date: 22 Mar 2006 09:04:29 +0100
In-Reply-To: <20060321174903.GG15742@pervasive.com>
Message-ID: <87slpaj46q.fsf@meuh.mnc.lan>
Lines: 40
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: amavisd-new at mnc.ch
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.104 required=5 tests=[AWL=0.104]
X-Spam-Score: 0.104
X-Spam-Level: 
X-Archive-Number: 200603/439
X-Sequence-Number: 17876

"Jim C. Nasby" <jnasby 'at' pervasive.com> writes:

> 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

Yes, we use 7.4.5 actually, because "it just works", so production
wants to first deal with all the things that don't work before
upgrading. I have recently discovered about the background writer
of 8.x which could be a supplementary reason to push for an
ugprade though.

> 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.

Ok, I see. Thanks for the info!

-- 
Guillaume Cottenceau