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,
Date: Tue, 21 Mar 2006 11:49:03 -0600
Message-ID: <20060321174903.GG15742@pervasive.com> (raw)
In-Reply-To: <87acbkkl0o.fsf@meuh.mnc.lan>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jnasby@pervasive.com, gc@mnc.ch
Subject: Re: planner with index scan cost way off actual cost,
In-Reply-To: <20060321174903.GG15742@pervasive.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox