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 319509DC8DF for ; Tue, 21 Mar 2006 21:08:22 -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 07777-03 for ; Tue, 21 Mar 2006 21:08:25 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from moonunit2.moonview.localnet (wsip-68-15-5-150.sd.sd.cox.net [68.15.5.150]) by postgresql.org (Postfix) with ESMTP id 119FC9DC8DE for ; Tue, 21 Mar 2006 21:08:19 -0400 (AST) Received: from [192.168.0.3] (moonunit3.moonview.localnet [192.168.0.3]) by moonunit2.moonview.localnet (8.13.1/8.13.1) with ESMTP id k2M1A34s006886; Tue, 21 Mar 2006 17:10:03 -0800 Message-ID: <4420A290.2050908@modgraph-usa.com> Date: Tue, 21 Mar 2006 17:04:16 -0800 From: "Craig A. James" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane CC: pgsql-performance@postgresql.org Subject: Re: Poor performance o References: <43F38867.6010701@gpdnet.co.uk> <19510.1140036968@sss.pgh.pa.us> <19779.1140038874@sss.pgh.pa.us> <43F39E53.1020009@gpdnet.co.uk> <20781.1140046109@sss.pgh.pa.us> <19570.1142971720@sss.pgh.pa.us> <442080D1.5090803@modgraph-usa.com> <6629.1142983995@sss.pgh.pa.us> In-Reply-To: <6629.1142983995@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.105 required=5 tests=[AWL=0.105] X-Spam-Score: 0.105 X-Spam-Level: X-Archive-Number: 200603/435 X-Sequence-Number: 17872 Tom Lane wrote: > "Craig A. James" writes: >> It looks to me like the problem is the use of nested loops when a hash >> join should be used, but I'm no expert at query planning. > > Given the sizes of the tables involved, you'd likely have to boost up > work_mem before the planner would consider a hash join. What nondefault > configuration settings do you have, anyway? shared_buffers = 20000 work_mem = 32768 effective_cache_size = 300000 This is on a 4GB machine. Is there a guideline for work_mem that's related to table size? Something like, "allow 2 MB per million rows"? I'm also curious why the big difference between my "Query #1" and "Query #2". Even though it does a nested loop, #2's outer loop only returns one result from a very tiny table, so shouldn't it be virtually indistinguishable from #1? Thanks, Craig