Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id 21576633283
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon,  2 Aug 2010 23:55:55 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 80440-07
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue,  3 Aug 2010 02:55:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id D29AD6321CA
	for <pgsql-performance@postgresql.org>;
	Mon,  2 Aug 2010 23:55:47 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o732tj45007125;
	Mon, 2 Aug 2010 22:55:45 -0400 (EDT)
To: Peter Hussey <peter@labkey.com>
cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Questions on query planner, join types, and work_mem 
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>
Comments: In-reply-to Peter Hussey <peter@labkey.com>
	message dated "Mon, 02 Aug 2010 14:23:05 -0700"
Date: Mon, 02 Aug 2010 22:55:45 -0400
Message-ID: <7124.1280804145@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201008/26
X-Sequence-Number: 39869

Peter Hussey <peter@labkey.com> writes:
> My questions are still
> 1)  Does the planner have any component of cost calculations based on the
> size of work_mem,

Sure.

> and if so why do those calculations  seem to have so
> little effect here?

Since you haven't provided sufficient information to let someone else
reproduce what you're seeing, it's pretty hard to say.  It might have
something to do with the particularly wide join key values you're using,
but that's mere speculation based on the one tidbit you provided.  There
might be some other effect altogether that's making it do the wrong thing.

> 2) Why is the setting of work_mem something left to the admin and/or
> developer?

Because we're not smart enough to find a way to avoid that.

			regards, tom lane