pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Hannu Krosing <hannu@2ndquadrant.com>
To: Peter Hussey <peter@labkey.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Questions on query planner, join types, and work_mem
Date: Tue, 03 Aug 2010 10:03:51 +0300
Message-ID: <1280819031.14579.38.camel@hvost> (raw)
In-Reply-To: <AANLkTik3oY1=F_uC843c84LxBLNdHxZaWdfjxrAtyBeu@mail.gmail.com>
References: <AANLkTikMwVZKDYLitnsK31R=VNOuTH8NtmDHDGkBR7k8@mail.gmail.com>
	<18551.1280275502@sss.pgh.pa.us>
	<AANLkTimXMR0jMdw+66E4Xx=SqNV37Ne9WfkFjPFZVjbV@mail.gmail.com>
	<25534.1280498632@sss.pgh.pa.us>
	<AANLkTik3oY1=F_uC843c84LxBLNdHxZaWdfjxrAtyBeu@mail.gmail.com>

On Mon, 2010-08-02 at 14:23 -0700, Peter Hussey wrote:
> I already had effective_cache_size set to 500MB.
> 
> I experimented with lowering  random_page_cost to 3 then 2.  

In case of fully cached database it is closer to 1.

> 2) Why is the setting of work_mem something left to the admin and/or
> developer?  Couldn't the optimizer say how much it thinks it needs to
> build a hash table based on size of the keys and estimated number of
> rows?

Yes, It can say how much it thinks it needs to build a hash table, the
part it can't figure out is how much it can afford, based on things like
number concurrent queries and how much work-mem these are using, and any
work-mem used will be substracted from total memory pool, affecting also
how much of the files the system caches.

> It is difficult for a software development platform like ours to take
> advantage of suggestions to set work_mem, or to change the cost
> function, or turn on/off join strategies for individual queries.  The
> SQL we issue is formed by user interaction with the product and rarely
> static.  How would we know when to turn something on or off?  That's
> why I'm looking for a configuration solution that I can set on a
> database-wide basis and have it work well for all queries.

Keep trying. The close you get with your conf to real conditions, the
better choices the optimiser can make ;)



-- 
Hannu Krosing   http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability 
   Services, Consulting and Training





view thread (32+ messages)  latest in thread

Message-ID: <1280819031.14579.38.camel@hvost>
Permalink:  ../1280819031.14579.38.camel@hvost/
Also on:    postgresql.org/message-id/1280819031.14579.38.camel@hvost

 · 

reply

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: hannu@2ndquadrant.com, peter@labkey.com, tgl@sss.pgh.pa.us
  Subject: Re: Questions on query planner, join types, and work_mem
  In-Reply-To: <1280819031.14579.38.camel@hvost>

* 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